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ABSTRACT 


The purpose of this thesis is to design a type checker for the SPEC language and to 
investigate its implementation using an attribute grammar tool. SPEC is a formal 
language for writing black-box specifications for large software systems. The type 
checker is a software tool which verifies the semantic accuracy of the declarations and 
their uses in a SPEC source program. The design specifically addresses language 
features which are especially important for large software system specification such as 
generic parameters, name and operator overloading, subtypes, importation and 
inheritance. Additional discussion 1s provided concerning the handling of the "non-block 
structured" nature of the specification language. This thesis rmplements two of the three 
aspects of type checking--name analysis and error reporting. Additionally, a definitive 


framework is laid for the final aspect, type consistency analysis. 
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IL INTRODUCTION. 


The field of Software Engineering is a growing area of interest in computer science. 
Many systems are currently being developed, using various methodologies, to support 
large scale software development. One of these systems uses the functional specification 
language SPEC to define the syntax and semantics of these projects. SPEC is a language, 
developed by Berzins [Ref. 1], for writing black-box specifications for the components of 
the software system in the functional specification stage of software development. To 
increase the reliability of this code a type checking tool has been developed to 
semantically validate the various type declarations used in the specification. This thesis 


describes the methodology used and the actual implementation of this type checker. 


A. OBJECTIVES. 

The primary objective of this thesis 1s to design and implement a language dependent 
type checker for the specification language SPEC. Appendix A and [Ref. 1] contain a 
listing of the grammar for the SPEC language. The code for the type checker 1s wmitten 
entirely as an attribute grammar. This code is then compiled using the Kodiyak 
Application Generator, producing executable code. 

It is also desired that the type checker be easily modifiable in the event that 
extensions are incorporated into the SPEC language. By using an attribute grammar to 


specify the program and an application generator to generate the code, the program can 


be modified with relative ease. The efficiency of the code is not a limiting factor, 
because optimizations may be coded at a later date. 

The final objective is to abstract the process used to develop the type checker and 
develop an algorithm for producing type checkers for other specification languages. This 
algorithm will be a direct result of the insight gained from the design and implementation 


of the SPEC language tool. 


B. RESEARCH QUESTIONS. 

There are two pertinent research questions for this thesis. First, and foremost, what 
are the underlying issues in the design and implementation of a type checker for a 
specification language using an application generator? What is the impact of these issues 
on portability, readability, modifiability and efficiency of the code? 

Finally, how would this type checker be best integrated into a programming 
environment? What facilities must this programming environment provide? Should the 


type checker be optimized to provide better execution speed? 


C. THE HISTORY AND SUCCESSFUL APPLICATIONS OF ATTRIBUTE 
GRAMMARS TO SIMILAR PROBLEMS. 


Attribute grammars are frequently used for specifying the semantic meaning of 
source programming languages. Additionally, with the aid of application generators, 
these grammars have been used to generate compilers and other tools for the recognition 


and transformation of programs coded in these source languages. 


1. The Context Free Nature of SPEC--A Pretty Printer. 

All language grammars are classified by the complexity of the productions that 
produce that language. The Chomsky Heirarchy, named after Noam Chomsky, divides 
languages into four classes--type 0 (unrestricted) grammars, type 1 (context sensitive) 
grammars, type 2 (context free) grammars and type 3 (regular) grammars. Type 0 
grammars contain the set of all languages, type 1 contains a subset of that, etc. Of these 
four classes, type 3 (context free) and type 4 (regular) are of the most interest in 
programming language design because they can be used to describe the structure and 
basic symbols of a program. Most standard computer languages in use today can be 
described with a context free grammar since efficient parsing algorithms are known for 
this class of languages. The SPEC specification language is described using a context 
free grammar. 

A thesis recently completed at the Naval Postgraduate School [Ref. 2] developed 
a program using the Kodiyak application generator and an attmbute grammar to print 
SPEC specifications in a properly formatted / indented manner. The Kodiyak application 
generator is a tool for converting context free attnbute grammars into an executable 
program. This "Pretty Printer" program demonstrated that SPEC is indeed context free 
because the Kodiyak tool could convert the attribute grammar representation into 
executable code which formats SPEC specifications. The thesis also demonstrated that 


attribute grammars are a feasible way to create tools for the SPEC language. 


2. MSG.84 and MSG.85--A Translator for a Specification Language. 

MSG.84 and MSG.85 are specification languages developed at the University of 
Minnesota. They have been used extensively in software engineering classes for 
specifying software systems. In the Spring of 1984, a translator was written to translate 
these specifications into the Lisp-like DBL [Ref. 3] assertions. This translator, from 
which the Kodiyak application generator evolved, revealed some design flaws in the 
MSG language. These flaws were corrected and a translator now exists for the 
conversions. Additionally, a reverse translator was written to convert the DBL assertions 
produced into MSG. This process of translation and reverse translation insured that the 
translation to DBL was "lossless" and that the semantic meaning of all the MSG 


constructs was preserved. 


3. The Design of a Compiler--Farrow 1984. 

Attribute Grammars have long been championed as a promising basis for 
compiler writing systems. Many different compiler-compilers such as Yacc [Ref. 4], 
Linguist [Ref. 5] and Kodiyak [Ref. 6] have been developed. One of the major 
drawbacks however, has been the inability of these compilers to compete in the 
commercial market with those compilers produced by other means due to their memory 
requirements and speed. The Pascal-86 compiler developed by Intel Corporation is based 
on an attribute grammar and application generator. It was successfully marketed as a 
production compiler and was developed in a two stage process. The first phase was 
developed using the Linguist-86 application generator and performed semantic analysis, 


storage allocation and translation to intermediate code. The second part of the compiler 


takes the intermediate code produced by the semantcist unit and generated 8086 
microprocessor object code. The compiler has been marketed succesfully and it was 
noted that the development process was significantly enhanced due to the use of an 
attribute grammar. 

4. Syn--A Graphical Representation of Bachus Naur Form. 

Syn is a translator developed with the Kodiyak application generator that 
translates a grammar expressed in the Bachus Naur Form into directives in the PIC 
graphics language. The translator required approximately two man-weeks of work to 
implement by a user initially unfamiliar with the Kodiyak application generator [Ref. 6]. 
The significant time savings realized by the use of an application generator in the 
development of this tool reaffirms that application generators are an effective tool for 


developing large applications. 


5. The Chameleon Architecture. 

The Chameleon project {Ref. 7] is an ongoing project at Ohio State University 
that is developing an architecture to support the specification, construction and use of 
data translation tools. The architecture’s primary tool is an application generator that will 
take attribute grammar specifications and produce the tools needed to translate the data. 
An application generator was choosen as the primary tool in this architecture due to the 


readability and ease of understanding of the attribute grammar specifications. 


D. A SPECIFICATION TYPE CHECKER AND "CASE". 
1. Description of CASE. 

CASE is an acronym for Computer. Aided Software Engineering, an area of 
ongoing research at the Naval Postgraduate School. Some of the projects currently being 
developed in this area include a Software Rapid Prototyping System, Syntax-directed 
editors for SPEC and formatters for the SPEC language. Eventually, all of these tools 
will be integrated into an environment to aid the software engineering process and 
specifically ADA program development. It is also anticipated that this type checker and 
its principles will be integrated with a syntax directed editor to build a superior editing, 
type checking tool. 

2. Benefits for CASE. 

A type checker would be an extremely valuable addition to any CASE 
environment. Since it has been proven that many design errors manifest themselves as a 
type inconsistency, the type checker would assist in the identification of errors that could 


defeat the reliability of the specification. 


Il. BACKGROUND. 


A. TYPE CHECKER. 
1. Definition. 

A Type Checker is a tool used to validate the semantic accuracy of the uses and 
declarations of name structures in a program. There are two types of type checkers 
currently in use today. The kind of type checker used for a language is often dependent 
on the features of that language. The first kind, a dynamic type checker, executes 
concurrently with the program and checks the validity of dynamically declared variables 
as they are encountered. Since this tool runs as part of the executable program, the 
program performance is degraded and errors are reported during mun time instead of 
before the compile - link cycle. 

The second kind of type checker is a static type checker. This tool takes as input 
a file or multiple files containing the source program / specification and provides the user 
with a report detailing any type inconsistencies that were discovered. It can be run before 
a program is compiled and reports inconsistencies so that they may be corrected before 
the compile - link cycle. 

The process of validating the semantic accuracy of the structures in a program is a 
multi-part process. The first part, called name analysis, entails finding the definition of 
that name applicable to each use of the name. If there has been no definition of that 


name, the type checker will either make a definition based on the name’s use or report an 


error. The other two phases deal with obtaining the operator being used and confirming 
that the results of the name analysis are indeed allowable with the given operator. 
Additionally, a type checker must consider various language features such as operator 
overloading, name scoping and the binding method used. 
2. Scope Considerations. 

The scope of a name is the portion of the program over which it may be used 
(Ref. 8]. Many languages, called block structured languages, allow the nesting of various 
names within themselves. The most recent occurence defining the currently available 
definition of that name. Another constraint imposed by scope is whether or not a variable 
is visible inside of the structures that are declared inside of it. Both of these constraints 


and others must be considered in the design of the type checker. 


B. ATTRIBUTE GRAMMARS. 


1. Attribute Grammars. 

Attribute grammars were introduced by Knuth [Ref. 9] and advocated as a means 
of translating grammar specifications into executable code. They have been used 
repeatedly to develop compilers, compiler-compilers (application generators) and other 
useful tools. One of the most significant features of attribute grammars is their 
readability. Attmbute grammars are very similar to the Bachus-Naur form (BNF) of 
representing the syntactic structure of a program and tends to be self-documenting since 


they represent a relation between the syntax and semantics of the language. 


a. Definition. 

An attribute grammar is based upon a context-free grammar G = (N, T, P, Z) 
and associates a set A(X) of attmbutes with each symbol, X, in the grammar G. The 
context-free grammar is used to represent the syntactic structure of the language while 
the attributes are used to represent context-sensitive (semantic) properties of the 
language. 

b. Synthesized and Inherited Attributes. 

The attributes of an attribute grammar may be divided into two classes. The 
first of these, synthesized attributes, are those attributes of symbols on the Left hand side 
of a production that are derived from the return value of the elements on the right-hand 
side of the production. Conversely, inherited attributes are those attributes of symbols 
on the right hand side whose values are derived from the values of the attributes of the 


symbols on the left hand side. 


c. Semantic Functions. 

Each rule in an attribute grammar has semantic functions associated with it 
that define the values of some attmbutes in the production in terms of other attributes in 
the function. These functions resolve the actions that the application generator takes 
upon recognizing the production associated with them and define the values of all 


inherited and synthesized attributes. 


2. Automatic Parsing of Attribute Grammars--Application Generators. 
Application generators have many different uses. They have been used frequently 


for the implementation of compilers, the verification of the context sensitive constraints 


on languages and are becoming popular for the design and implementation of various 
other tools. One of their most significant advantages is that they let the user customize 
and reuse a general software design easily. 

a. Definition and Overview. 

Application generators are tools that produce executable code from a grammar 
specification. The executable program produced will model the semantic meaning of the 
grammar specification precisely. The application generator consists of two parts, a 
variant part and an invariant part. The invariant part consists of fixed assumptions about 
the domain or implementation such as the source language. The variant part of the 
application generator corresponds to the attnibute grammar specification of the system 
that is to be produced. 

The process of using the application generator begins with the attribute 
grammar specification. This specification is generally simpler, in both syntax and 
semantics than the programming language it specifies. Acting much like a language 
compiler, the application generator takes this specification and produces code in some 
invariant language (e.g., "C") which is then compiled with a standard compiler to 
produce the executable application. An end-user may then take this executable 
application and provide it with input from which the application will produce whatever 
the original specification specified. 

There are many different considerations in the choice of an application 
generator for a specific task. The first and foremost of these is if the application 


generator can perform the task desired. Other considereations include what built-in types 


and operators are available in the applications generator, the readability of the 
specification language (attribute grammar) used by the tool, the availability of the 
generator itself and the attribute evaluation method. 


b. The Semantic Tree. 

The basic principle of operation behind an application generator and its 
associated attribute grammar is that any program can be represented by a semantic tree. 
This tree will contain nodes, the interior ones representing productions and the leaves 
representing terminal symbols in the target language. Associated with each node is it’s 
attributes. 

c. Semantic Analysis. 

The process of evaluating each node in the semantic tree is called semantic 
analysis. As the attributes of each node are evaluated, the semantic functions are 
executed and any side-effects associated with them are performed. Different algorithms 
have been derived for resolving the attnbutes in the semantic tree and most of them have 
been implemented in at least one application generator. The choice of the algorithm 
depends on the properties of the attnbute grammar and the qualities desired in the 
resultant product [Ref. 6]. To ensure that the translator produced by the application 
generator performs exactly as desired, it is imperative that the method used to evaluate 
the attributes be understood. 

d. Advantages and Disadvantages. 
Application generators produce tools that are more reliable than a conventially 


coded tool because of their very nature. Since it accepts a specification of the tool to be 


produced and uses well-known techniques, it is less likely to accept syntactically 
incorrect input and generate unexpected output or terminate abnormally [Ref. 6]. Since 
there is a close link between the syntax and semantics of the specification, the volume of 
code required is reduced and it is more repairable. The application generator tends to be 
self-documenting because its source code allows users to quickly determine the syntactic 
requirements of programs. If an application generator is constructed properly it can be 
very portable. Typically it can be written in its own language and it produces an 
appropriate, portable target language, the application generator can be transfered to other 
computers with relative ease. 

The most important advantage of an application generator is its ability to cut 
down on the time and cost to build a tool with it. Since a programmer’s productivity is 
largely constant in the number of lines of code produced per unit time [Ref. 10], a tool 
that generates a program equivalent to a high level language program with less actual 
lines of code will increase productivity. Additionally, since there is generally a close 
correlation between the Bachus-Naur representation of the grammar and the specification 
input to the application generator, the time involved in the development of the program is 
decreased as it is with most fourth generation languages [Ref. 11]. 

A major drawback of application generators is that since they are table driven, 
they tend to produce executable code that is not as efficient as equivalent "hard-coded" 
tools. Additionally, since the value of the attributes used must be copied between 
attributes so that these values may reach the root to be output, bulk is added to the 


program’s specification. Both of these problems are currently being researched. Some 
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solutions have been put forth. To reduce the number of copy rules (and thus increase 
readability), a macro preprocessor may be used. Additionally, research has proven that 
hard-coding the tables used during the evaluation process tends to produce a speedup 


factor of 6-10% [Ref. 12]. 


e. Existing Application Generators. 

Many different application generators have been developed. Some of the 
most popular include the HLP (Helsinki Language Processor) system [Ref. 13], Delta 
[Ref. 14], Mug2 [Ref. 15], Aparse [Ref. 16] Gag [Ref. 17], YACC [Ref. 4], Linguist-86 
[Ref. 5] and Kodiyak [Ref. 6]. Each uses a different algorithm for evaluating the 


attributes of the semantic tree and accepts different classes of attribute grammars. 


C. THE KODIYAK APPLICATION GENERATOR. 

The Kodiyak application generator was developed at the University of Minnesota and 
is intended for building prototype languages and translators. The specification describes 
all aspects of translation: input scanning, parsing, semantic Baeceeen ana output. It has 
been used to build translators for other specification languages, text processing tools, 


database query languages and a pretty printer for the SPEC language. 


1. Justification for use. 

Kodiyak is an exceptional language translator that integrates the functions of the 
YACC [Ref. 4] parser generator and LEX [Ref. 18] scanner generator into a 
comprehensive whole, hiding the procedural and interface details of these tools. Its 
compact attribute grammar specification describes every aspect of the translation process, 


produces portable "C" language code and then compiles that into executable code. 
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Additionally, Kodiyak can process it’s input through a macro-preprocessor allowing 
repetitive code to be replaced by a single statement thus improving a programs’ 
readability. Kodiyak allows evaluation of the largest class of attribute grammars and 
contains built-in types capable of specifying symbol tables. Its many features, 
capabilities, portability, and availability make it an ideal tool for the implementation of 
this thesis. 

2. A General Description of the Kodiyak Language. 

All of the points covered in the following section come directly from Appendix A 
of Herndon [Ref. 6] Kodiyak Program Layout. It is intended to describe the operation of 
the Kodiyak translator in sufficient detail to facilitate understanding of the type checker 
code. It is not intended to be a detailed reference. If further or more detailed information 
is needed it is recommended that Herndons’ doctoral dissertation [Ref. 6] be consulted. 

a. Format. 

Every Kodiyak program has three sections. The first section describes the 
features of the lexical scanner that is to be used to translate the source text into tokens 
and operator precedences and associativities for those tokens. The second section 
declares the names and types of the attributes associated with each grammar symbol. 
The third section contains the grammar and attribute equations that define the translation. 


These sections are separated by a double percent symbol ("%%") on a line by itself. 


b. Comments. 
There are two forms of comments in Kodiyak. The first is the C and PL/I 
style comment delimined by "/*" and "*/". The second is introduced by an exclamation 


point "!" and continues to the end of the line. 


c. Lexical Scanner Section. 

Each statement in the lexical section of a Kodiyak program describes the 
terminal symbols of the translation in some way. The primary function of statements in 
this section is to specify the terminal symbols of the grammar, and how input text is to be 
transformed into these symbols. The secondary function of this section is to specify a set 
of operator precedences to be used with the grammar. 

The transformation of input text to terminal symbols is denoted by a regular 
expression. Figure 2.1 shows examples of lexical definitions. These definitions are an 
excellent sampling of the typical definitions. The first definition demonstrates the 
general format of a lexical definition. The second definition demonstrates how a specific 
string can be recognized and the third definition shows how a changeable string of text, 
such as a variable name, may be recognized. The rules are examined in the way they are 
listed, thus implying precedence. The first rule that is recognized will determine the 


terminal symbol (token) that will be returned. 


TERMINAL_NAME : REGULAR_EXPRESSION 


' Format for a lexical definition. 
! A Terminal_name is specified by the Regular_expression. 


BEGIN : "BEGIN" | "begin" 


! The terminal symbol BEGIN is recognized if either "BEGIN" or 
! "begin" is scanned from the input 


‘[A-Za-z][A-Za-z0-9]" 


! The terminal symbol ID is recognized if a string starting with 
! an alphabetic character followed by zero or more alphanumeric 
! characters 1s scanned from the input. 





Figure 2.1 
Sample Lexical Definitions. 


Operator characters are an extremely important part of any regular expression. 
They allow ways for specifying choices, repeating characters and ranges of characters. 
All valid operator characters used in Kodiyak regular expressions are enumerated in 
Figure 2.2. If you desire additional information on construction of regular expressions 


and further examples, the original Lex documentation [Ref. 18] provides an authoritive 


source. 
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Operator Symbol 


Meaning 
Delimiter between Token name and regular expression. 


By preceding an operator character with the backslash, the 
operator will be recognized as a text character. 


Whatever is contained between a pair of quotes is text characters. 
Indicates a character class. Any character between the brackets 
will be recognized. The only operator symbols having meaning 
between brackets are "-", "\" and "A", 
If the Caret Symbol appears outside of a set of brackets, the 
string following it must appear at the beginning of a line 
to be matched. If it appears as the first character after a 
left bracket, it indicates that the resulting string is to be 
complemented. (i.e. [Aabc] matches everything except a,b orc. 
Symbolizes an expression that is to be repeated one or more times. 
Symbolizes an expression that is to be repeated zero or more times. 
Indicates alternation. It may be interpreted verbally as an “or”. 


Parenthesis are used for grouping. 


If the very last character of a regular expression is the dollar 
sign, the expression will only be matched at the end of a line. 


The forward slash between two regular expressions means that the 
terminal symbol is only matched if the first regular expression 
is immediately followed by the second regular expression. 

The question mark precedes an optional part of an expression. 

The dash operator specifies ranges. 

The period operator matches any character. 

Curly Braces specify either repetition or definition expansion. 


Figure 2.2 
Lexical Section Operators. 
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Kodiyak also provides ways to increase the readability of regular expressions. 
By defining the basic lexical classes (digits, alphabetics, integers, etc.), the regular 


expressions may be made more readable. Figure 2.3 provides an example of this feature. 


%define Letter : [a-zA-Z] 


S%odefine Int : (Digit}+ 


%define Alphanum : [{Digit} (Letter}] 


COMMENT ee Nn" 


NAME : (Letter) {Alphanum }* 





Figure 2.3 
Regular Expressions with Definitlon Expansion. 


d. Attribute Declaration Section. 

The attribute declaration section of a Kodiyak program declares the attributes 
used in the program and their types. In this version of Kodiyak, no other statements may 
be present in this section, though it is expected that declarations of constant functions and 
external functions and procedures will eventually be allowed in this section. 

Kodiyak supports two primitive data types for attributes: strings and integers. 
Strings may have arbitrary length and may be concatenated to form longer strings. All 
simple mathematical functions (i.e., addition, subtraction, multiplication and division) 
may be applied to integers. 

Kodiyak also supports higher order types. These types are called maps, and 
define functions that may map any primitive type to any other type. Maps are extremely 


flexible and important to the type checker. They can be mapped onto other maps to form 
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something similar to high level languages record structures. Figure 2.4 shows a some 


sample attribute declarations. 





Figure 2.4 
Sample Attribute Declarations. 


This figure declares that four attributes (type, %text, %line and value) are to 
be associated with the grammar symbol ID and that two attributes (type and e_valid) are 
to be associated with expressions (EXPR). Furthermore, attributes type and %text are 
attributes that may take on string values; %line and value may take on eas values and 
attribute e_valid is a map from a string ("true’ or "false") to an integer value (1 or 0). 

Figure 2.4 also demonstrates two very important concepts in Kodiyak. First, 
since an identifier (ID) is normally a terminal symbol and an expression (EXPR) is a 
non-terminal, both terminals and non-terminals can have attnbutes. Secondly, terminal 
symbols can have two special, predefined attributes associated with them, "%text” and 
"%\ine". These attributes are initialized when the terminal symbol is recognized to be the 


actual text scanned and the input line on which the text was found. 
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e. The Attribute Grammar and Semantic Function Section. 

The final section of a Kodiyak program defines the syntax and semantics of 
the translation. It consists of a set of rules and sets of equations defining evaluation rules 
for the attributes. There is one distinct start symbol for the rules and it is defined as the 
symbol on the left hand side of the first rule in the grammar. This symbol is unique and 
it may not appear on the right hand side of any rule in the grammar. 

Rules in Kodiyak are defined in a form that is very similar to Bachus-Naur 
Form (BNF). Figure 2.5 defines a rule which specifies that the non-terminal symbol 
“non” will be recognized if the symbols "sym1", "sym2" and "sym3" appear in sequence. 
Additionally, if the symbol "non" is recognized, the semantic functions defined between 


the curly braces will be computed during the attribute evaluation process. 


syml sym2 sym3 


! semanuc funcuons go here. 


} 





Figure 2.5 
Rule Template. 


The semantic functions must have a way of specifying exactly what attributes 
are to be used during the determination process. In Figure 2.6 one rule has been used to 
demonstrate the three different ways of accessing the same attributes. In the first part of 
the rule, a production allowing an expression to be recognized when two expressions are 
separated by a plus ("+") sign is detailed. Associated with it is a semantic function 


Stating the value attribute of the expression on the left hand side of the rule (specified by 
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the "$$.value" notation) will be assigned the contents of the first expression’s value 
attribute ("$l.value") added to the contents of the second expression’s value attribute 
("$3.value"). The second and third notation show the exact same effect using 
subscripting. In these examples, the subscript refers to each occurence of the non- 
terminal. If a subscript is left out, as in the second notation, the non-terminal is assumed 


to refer to the non-terminal on the left hand side of the equation. 


expr ’+’ expr 
{ 
$$.value = $1.value + $3.value 


expr ’-’ expr 


expr.value = expr[2].value - expr[{3].value 


} 


expr’*’ expr %prec multiply 


expr[{1].value = expr[2].value * expr[3].value 
} 





Figure 2.6 
Attribute Naming and Rule Concepts. 


Kodiyak has arich set of operators. Besides the various arithmetic and string 
operators detailed previously, it also provides nine logical operators. Figure 2.7 


enumerates all of the operators that are presently available. 
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Operator Symbol Meaning. 
# Multiplication 

Subtraction 
Division 
Concatenation 
Concatenation 
Less than 
Greater than 
Equal to 
Not equal to 


Less than or equal to 


Greater than or equal to 


Logical and 
Logical Or 


Logical negation 





Figure 2.7 
Kodiyak Operators. 


Kodiyak also provides a means of specifying a statement equivalent to the 
"IF" construct used in high level languages. This construct has different syntax than most 
languages, but is logically equivalent. Figure 2.8 demonstrates this construct using the 


“expr’ rule introduced in Figure 2.6. 
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expr ’/’ expr 


$$.value = ($3.value <> 0 
-> $l.value / $3.value 
# s2i("0") 





Figure 2.8 
Kodiyak “if..Then..Else” Construct. 


The above example assigns to the value attribute of the left part symbol the 
contents of the first expression divided by the contents of the second expression if the 
contents of the second expression are not equal to zero. If the second expression’s 
contents are equal to zero, a value of O is assigned to the resultant expression’s “value” 
attribute. The "else" ("#") clause also introduces another very important feature of 
Kodiyak--built in functions. In Figure 2.8, the string to integer (s2i") function was 
called to convert a string value into an integer. Kodiyak’s standard functions are 


enumerated in Figure 2.9. 
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Funcuon Name 


fmt(formatarg 1...) 


i2s(integer) 

s2i(string) 

len(string) 

inputfile(O) 

outputfile(0) 

basename(file:string) 

J%output(val:string) 

% error(val:string) 

%assert(condition: boolean, 
message : string) 

%outfhile(name : string, 
val : string) 


%errfile(name : string, 
val : string) 


Purpose 


Generates a string in the format defined by the 
"format" parameter, with argl,... substituted. 


Converts an integer value to a string representation. 


Converts a character string to an integer. 


Retums the length of a string. 

Retums a string naming the input file. 

Returns a string naming the output file. 

Retums a copy of a string without dotted extension. 

Val is written to the standard output 

Val is written to the standard error. 

If the value of condition is false, Kodiyak prints 
message to the standard error file and terminates, 


otherwise, the procedure does nothing. 


Val is written onto the file "name". 
If name is null, val goes to stdout. 


Val is written into the file "name". 
If name is Null, val goes to stderr. 





Figure 2.9 
Kodiyak Functions. 


f. Using the Kodiyak Translator. 
The Kodiyak compiler creates and processes many files. Among them are 
files that are processed by YACC, LEX, and by the C compiler. The Kodiyak 
compilation process also depends upon two predefined files. The first is the Kodiyak 


library. This contains functions for creating the parse tree, evaluating attributes, 
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concatenating strings, etc. The second file is the user library. This is a set of C functions 
that the programmer may define for himself. 

The command to invoke the Kodiyak translator is "k program.k" where 
“program.k" is the kodiyak program to be compiled. Files to be compiled should have 
the extension ".k" or the compiler may not accept it. Kodiyak programs may also have 
the extension ".m4" if the program is to be run through the macro-preprocessor prior to 
Kodiyak compilation. 

After the program is compiled, (assuming no errors are present), the resulting 


object code will be in the file "program" in the current directory. 


D. THE SPEC LANGUAGE. 

SPEC is a formal language for writing black-box specifications for components of 
software systems. SPEC uses the event model to define the black-box behavior of 
proposed and external systems. Black-box specifications are developed for the external 
interfaces of the system in the functional specification stage of eoriware development, 
and for the internal interfaces in the architectural design stage. Discussion of the event 
model and the SPEC language, extracted from [Ref. 1:pp. 3.1-3.15], follows. Appendix 
A and [Ref. 1] contain a listing of the grammar for the SPEC language. 

1. The Event Model. 

In the event model, computations are described in terms of events, modules and 
messages. An event occurs when a message is received by a module at a particular 


instant of time. A module is a black box that interacts with other modules only by 
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sending and receiving messages. A message is a data packet that is sent from one 
module to another module. 

Modules can be used to model external systems such as users and peripheral 
hardware devices, as well as software components. A module has no visible internal 
structure. The behavior of a module is specified by describing its interface. The 
interface of a module consists of the kinds of events that can occur at the module along 
with its response to each kind of event. Each kind of event corresponds to a different of 
incoming message. Each response consists of the later events directly triggered by a 
given initial event. 

Any module accepts messages one at a time, in a well-defined order that can be 
observed as a computation proceeds. Message transmission is assumed to be reliable. 
Messages can have arbitrarily long and unpredictable transmission delays. The order of 
messages arriving is normally not under control of the designer. 

In the event model each module has its own local clock. The local clocks of 
different modules are not necessarily synchronized with each other. Each event occurs at 
a well-defined instant of time, which 1s the time at which the destination module receives 
a message, according to its own local clock. The length of time between two events is 
precisely defined if both events occur at the same place. The length of time between two 
events at different locations can be estimated in terms of two readings of the same clock, 
but this is only an approximation because of unpredictable message delays in obtaining 


remote clock readings. The only kind of time interval meaningful in the event model is 
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the duration between two events. There is no way to distinguish between computation 
delay and communication delay in the event model. 

Each message has a sequence of zero.or more data values associated with it. The 
other attributes of a message are its name, its condition and its origin. All of these 
attributes are single valued. Exceptions are modeled as messages by means of a 
condition attribute, which can take on the values "normal" and "exception". The 
condition of a message expressing a normal request for service is "normal". The 
condition of a message reporting an abnormal event somewhere is "exception", in which 
case the name of the message is the name of an exception condition. 

The response of a module to a message is completely determined by the sequence 
of messages received by the module since it was created. A module is mutable if the 
response of the module to at least one message it accepts can depend on messages that 
arrived before the most recent incoming message. A module is immutable if the response 
of the module to every possible message is completely determined by the most recent 
incoming message. Mutable modules behave as if they had internal states or memory, 
while immutable modules behave like mathematical functions. A module is immutable if 
and only if it is not mutable. 

Each module has the potential of acting independently, so that there is natural 
concurrency in a system consisting of many modules. Since events happen 
instantaneously and the response of a module is not sensitive to anything but the 
sequence of events at the module, the event module implies concurrent interactions with 


a module cannot interfere with each other at the level of individual events. This non- 
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interference must be guaranteed by implementations which require a finite time interval 
to trigger the responses to an event. The response of a module is under the control of the 
designer. 

In modeling concurrent systems it is sometimes necessary to specify atomic 
transactions. Atomic transactions are non-interruptible sequences of events at a module. 
Once a module starts an atomic transaction, it cannot accept any messages that are not 
part of the transaction until it is complete. Atomic transactions are sometimes needed to 
specify non-interference between concurrent sets of activities involving chains of 
multiple events at the same module. Atomic transactions must be used with care because 
they can lead to deadlocks if the protocols of the modules involved in a transaction are 
not compatible with each other, and can lead to starvation if a transaction goes on 
forever. 

Modules can be used to model current and distributed systems, as well as systems 
consisting of a single sequential process. The event model helps to expose the 
parallelism inherent in a problem, because the only time orderings specified are those 
which are unavoidable and are agreed on by all observers. 

Events can be triggered at absolute times. Such events are called temporal events. 
Temporal events are the means by which modules can initiate actions that are not direct 
responses to external stimuli. Formally a temporal event occurs when a module sends a 
message to itself at a time determined by its local clock. Unless explicitly stated 
otherwise, there may be an unpredictable delay between the time when the message is 


sent and the time when it is received, just like for any other message. 
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2. The SPEC Language. 

The SPEC language uses second order logic for the precise definition of the 
desired behavior of modules. The Spec language provides a means for specifying the 
behavior of three different types of modules: 

(1) Functions 

(2) State machines 

(3) Types 

Each of these types of modules is described in the following pages along with 
examples of each type of module. 

a, Functions. 

Function modules are immutable and calculate functions on data types, where 
“function” is interpreted as in standard mathematics. Usually function modules provide 
only a single service and hence accept anonymous messages. Figure 2.10 gives an 


example of the specification for a square root function. 
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FUNCTION square_root{ precision:rea!} 
WHERE precision > 0.0 


MESSAGE (x:real) 
WHEN x>= 0.0 
REPLY (y:real) 
WHERE y >= 0.0 & approximates (y*y,x) 
OTHERWISE REPLY EXCEPTION imaginary_square_root 


CONCEPT approximates (rl r2:real) 
--True if rl is a sufficiently accurate 
--approximating of r2. 
--The precision is relative rather than absolute 
VALUE (b:boolean) 
WHERE b<=> abs ((rl - r2)/r2) <= precision 
END 


Note: "--" introduces a comment and all keywords 
in Spec appear in all capital letters 





Figure 2.10 
Function Example. 


b. State Machines. 

A machine is a module with an internal state, 1.e., machines are mutable 
modules. Figure 2.11 shows an example of a machine. The behavior of the machines is 
described in terms of a conceptual model of its state, rather than directly in terms of the 
messages that arrived in the past, because descriptions in terms of such a conceptual 


model are usually shorter and easier to read. 
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MACHINE inventory 
--assumes that shipping and supplier are other modules 
STATE (stock:map {item,integer}) 
INVARIANT ALL (i:item::stock[1] >= 0) 
INITIALLY ALL (i:item::stock[1] = 0) 


MESSAGE receive (i:item,q:integer) 
--Process a shipment from a supplier. 
WHEN q > 0 
TRANSITION stock[1]=*stack[i] + q 
--Delayed responses to backorders are not shown. 
OTHERWISE REPLY EXCEPTION empty_shipment 


MESSAGE order (io:item,qo:integer) 
--Process an order from a customer. 

WHEN 0 < qo <= stock[io] 

SEND ship (is:item, qs:integer) TO shipping 
WHERE is = io, qs = qo 

TRANSITION stock[io] + qo = *stock[io] 

WHEN 0 < qo > stock[io] 

SEND ship (is:item, qs:integer) TO shipping 
WHERE is = is, qs = stock[io] 

SEND back_order (ib:item, qb:integer) TO supplier 
WHERE ib = io, qb + qs = qo 

TRANSITION stock[io] = 0 


OTHERWISE REPLY EXCEPTION empty_order 
END 





Figure 2.11 
Machine Example. 


c. Types 


A type module defines an abstract data type. An abstract data type provides 
many services therefore the messages of a type module usually have a name. An abstract 
data type consists of a set of instances and a set of primitive operations involving the 
instances. The instances are the individual data objects belonging to the type. The 


instances of an abstract data type are black boxes. The properties of the instances are not 


visible directly, and can only be observed and influenced by means of the primitive 
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operations. The properties of an instance are determined by the primitive.operation that 
created the instance and the sequence of primitive operations applied after it was created. 


Data types are either mutable or immutable. For immutable types the set of 
instances and the properties of each instance are fixed. Operations producing instances 


of the type are viewed as selecting members of this fixed set. Figure 2.12 is an example 
of an immutable abstract data type. 


TYPE rational 

INHERIT equality {rational} 

MODEL (num den:integer) 

INVARIANT ALL (r:rational::r.den ~= 0) 


MESSAGE ratio (num den:integer) 


REPLY (r:rationa!) 
WHERE r.num = num, r.den = den 
OTHERWISE REPLY EXCEPTION zero_denominator 


MESSAGE add (x, y:rational) OPERATOR + 
REPLY (r:rational) 


WHERE r.num = x.num*y.den+y.num*x.den, 
r.den = x.den*y.den 


MESSAGE muluply (x y:rational) OPERATOR * 
REPLY (r:rational) 


WHERE r.num = x.num*y.num, r.den = x.den*y.den 


MESSAGE equal (x y:rational) OPERATOR = 
REPLY (b:boolean) 


WHERE b <=> (x.num*y.den = y.num*x.den) 
END 





Figure 2.12 
immutabie Abstract Data Type. 


The state of a mutable data type consists of a set of instances which have 


internal states. The initial state of a mutable type is an empty set of instances. Mutable 
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types have operations for creating new instances, and usually also operations that can 
change the properties of an instance once it has been created. An example of a mutable 
abstract data type with immutable instances is the set of unique identifiers for the objects 
in a database. 

An instance of a mutable data type is very similar to a state machine, except 
that the state machine is implicitly created at the start of the computation, while the 
instances of a mutable data type are created as a computation proceeds. A state machine 
has exactly one instance, while a mutable data type can have any number of instances. 


Figure 2.13 is an example of a specification of a mutable data type. 


oD 


TYPE queue {t:type} 
INHERIT mutable {queue} 


--Inherit definitions of the concepts new and defined. 
MODEL (e:sequence) 

-The front of the queue is at the nght end. 
INVARIANT tue 


--Any sequence is a valid model for a queue. 


MESSAGE create 

--A newly created empty queue. 
REPLY (q:queue{t}) WHERE q.e = [J 
TRANSITION new(q) 


MESSAGE enqueue (x:t, q:queue{t}) 
--Add x to the back of the queue. 
TRANSITION q.e = append(([x], *q.e) 


MESSAGE dequeue (q:queue {t}) 

--Remove and return the front element of the queue. 
WHEN not_empty (q) 

REPLY (x:t) 

TRANSITION *q.e = append (q.e,[x]) 
OTHERWISE REPLY EXCEPTION queue_underflow 


MESSAGE not_empty (q:queue{t}) 
--True if q is not empty. 
REPLY (b:boolean) WHERE b <=> (q.e ~= []) 
END 





Figure 2.13 
Mutable Abstract Data Type. 
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HI. SYSTEM DESIGN. 


The first stage of the design effort was to analyze the requirements and obtain a better 
understanding of the SPEC language. To facilitate this process, a language reference 
manual [Ref. 19] was developed. This language reference manual describes many of the 
finer points in the SPEC language and provided a firm starting point for the type checker. 
It assisted in illuminating many of the issues that would have to be addressed in the 


design and capabilities that the type checker would have to encompass. 


A. SPEC LANGUAGE TYPE CONSISTENCY CONSTRAINTS. 
Like most computer languages, SPEC has many constraints on the naming and use of 


various operands. These constraints were derived from [Ref. 1] and [Ref. 19]. 
1. SPEC Language Semantic Issues. 
a. Definitions. 


e Descendant of a Module: A module is considered to be a descendant of another 
module if it explicitely inherits the traits of that module using an INHERIT 
clause. 


e Local: A name is local if it is only visible to the module / entity in which it is 
contained. 


¢ Global: A name is global if it is visible to the entire specification. 


e Signature: The signature of a name is the ordered set consisting of the actual 
name, the arguments associated with that name and the types associated with the 
arguments. 


e Boolean Value: A value that may only take on the logical values of "true" or 
“false”. 
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Unique Definition Constraint: Only one definition of a concept or message 
with the same signature is allowed to be visible in any of the modules in a well 
formed specification. 


Definition Consistency Constraint: Some concepts may have to be renamed 
before they can be imported or inherited. 


Import Consistency Contraint: A concept can be imported from another 
module only if the other module defines and EXPORT’s the concept. 


Instance Consistency Constraint: Requires that the actual parameters of an 
instance of a generic module must satisfy any constraints mentioned in the 
WHERE clause after the generic parameter declaration. 


Input Coverage Constraint: Requires every concept to have proper values for 
all possible inputs satisfying the precondition. Also, the WHERE and 
TRANSITION clauses of each message must have proper values for all states 
and input values satisfying the associated preconditions. 


Congruence Consistency Constraint: A property of MESSAGES and 
CONCEPTS that is true if they mean the same thing for all equivalent conceptual 
representations. 


Completed Specification: A specification that meets all of the Constraints and 
scoping requirements of the SPEC language and contains no instances of the not 
yet defined clause (""?"). 


b. Scoping. 


The names of MODULES are global and unique. No module name may be 
redeclared at any other point in the specification. 


The names of MESSAGES and EXCEPTIONS are global. 


The names of CONCEPTS are local to the module in which they are defined. 
Concepts may be inherited by another module with the use of an INHERIT 
Clause in that module. A Concept may only be associated with other modules if: 


(a) It is explicitly exported with an EXPORT clause and 


(b) It 1s explicitly imported into the module it is to be associated with by an 
IMPORT clause. 


The FORMAL PARAMETERS of a generic module are visible in the module in 
which these names are defined. 
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The component names of the MODEL of a type are visible in the module in 
which the names are defined and in any descendants of that module. 


The component name of the STATE of a machine are visible in the module in 
which the names are defined and in any descendants of that module. 


The FORMAL PARAMETERS of a message are visible to the entire 
specification of that message. 


The FORMAL ARGUMENTS of a message are visible to the entire specification 
of that message. 


The FORMAL ARGUMENTS of a reply clause are visible from their declaration 
to the end of the when or otherwise clause in which they are declared. If no 
when or otherwise clause exists, they are visible until the end of the message 
specification. 


The FORMAL ARGUMENTS of a send clause are visible from their declaration 
to the end of the when or otherwise clause in which they are declared. If no 
when or otherwise clause exists, they are visible until the end of the message 
specification. 


The FORMAL ARGUMENTS of a generate clause are visible from their 
declaration to the end of the when or otherwise clause in which they are declared. 
If no when or otherwise clause exists, they are visible until the end of the 
message specification. 


The visibility of LOCAL VARIABLES declared in a CHOOSE clause extends 
from their declaration to the end of the when or otherwise clause in which they 
are declared. If no when or otherwise clause exists, they are visible until the end 
of the message specification. 


The scope of variables bound to a quantifier extends from the "(" following the 
name of the quantifier to the matching ")”. 


All identifiers in SPEC must fall into one of the above categories. 
c. Naming Constraints. 


The name of a module is considered unique if there is only one module defined 
with its given name. 


The name of a message is considered unique if there is only one occurrence of 
that name with it’s specific signature within its scope. 


a) 


The operator of a message is considered unique if there is only one occurrence of 
that operator with the specific signature of its corresponding name within the 
operators scope. 


The name of a concept is considered unique if there is no other definition of that | 
name with the same signature within the name’S scope. 


Any other name construct is considered unique if there is no other occurence of 
that name within its defined scope. 


d. Type Consistency Constraints. 


An operation which is referenced to a specific module with the "@module" 
qualifier must be defined (or inherited by) the referenced module. 


If the "@module" qualifier is not used to clarify the use of an operator or 
message name, there must be exactly one candidate operation matching the types 
of the actual parameters. 


Arguments and Parameters in SPEC are specified by position. If a value or name 
is given for the arguments or parameters used in a call to a construct (the actual 
parameters), the types of the names or value must match the corresponding 
formal parameters or arguments. 


There must be a unique correspondence between the actual parameters and the 
formal parameters. For example, if the $ operator is used to specify a variable 
number of parameters in the formal definition, it must be determinable as to 
which actual parameters the $ will be bound. 


An expression following a WHERE clause must evaluate to a boolean value. 
An expression following a WHEN clause must evaluate to a boolean value. 


An expression following a SUCH THAT clause must evaluate to a boolean 
value. 


An expression following an IF or ELSE_IF clause must evaluate to a boolean 
value. 
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e The types of the expression following the specification of a quantifier must 
match the requirements of the quantfier. Predefined constraints are: 


ALL Boolean 

SOME Boolean : 

NUMBER Any type with an equality operator. 

SUM Any type with a commutative & associative "+" operation. 
PRODUCT Any type with a commutative & associative "*" operation. 
UNION Any type with a commutative & associative union. 


INTERSECT. Any type with a commutative & associative intersection. 
MAXIMUM Any type with a partial order "<=" operation. 
MINIMUM Any type with a partial order "<=" operation. 


e The expressions on either side of a conditional operator must be of the same 
type. 


e All of the normal REPLY clauses of the same message must be of the same type. 


e Allof the REPLY EXCEPTION clauses with the same exception condition in the 
same message must be of the same type. 


e The definition of each message used in an expression must not contain any 
TRANSITION clauses. 


e Ifa SPEC predefined operator is overloaded, the overloading message must have 
the same number of arguments as the defined operator in the SPEC library. For 
example, the "+" operator cannot be overloaded to a message that requires three 
arguments. 


B. CONCEPTUAL MODEL. 


1. Requirements. 
The SPEC type consistency constraints identified many different requirements for 


the type checker. The more distinct requirements are: 


e When a name is used in the specification, all defined argument lists for that name 
must be searched to determine the correct signature for that usage. If more than 
one possible matching signature is found, an error message must be reported 
listing all the conflicting usages. Figure 3.1 shows three skeleton modules. In 
the first two modules define two types, "nat" and "integer". They also define two 
messages, "add", each of which is a legal definition within its scope. The third 
module uses the "add" message. During the type checking process, an error must 
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be reported in function "does_something" stating that more than one possible 
signature match for the "add" message exists and reporting the conflicting 
bindings. 


TYPE nat 
MODEL 
INVARIANT true 


MESSAGE add (n: nat, 1: integer) 
REPLY (i2 : integer) WHERE i2=i1+n 


MESSAGE add (n: nat, 1: integer) 
REPLY (i2 : integer) WHERE 2 =1+n 
END 


FUNCTION does_something 
MESSAGE (i: integer, n : nat) 
REPLY (i2 : integer) WHERE i2 = add(n,i) 
END 





Figure 3.1 
Conflicting Name Bindlngs. 


e A data structure must be available at all times which retains the names, signature, 
operator(s), module name, return type and parameters for each message in the 
specification. 


e A data structure must be available during importation which retains the names, 
signature, module name, return type and parameters for each exported concept in 
the specification. 


e During name analysis, all module names must be examined prior to the 
examination of any other name. The examination of message names, concept 
names, a module’s formal parameters and the state or model clause variables 
should then be accomplished in order. 


e Any variable names or types declared within any other SPEC structure are visible 
within that structure only subject to defined visibility rules. 
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e The type of every visible name must be immediately determinable during the 
type checking process to enable type consistency checking. 


e Every name must be unique according to its scope and signature. If a name is 
not unique, an error must be reported. 


e All the formal arguments and parameters of a name must be retained in full (i.e., 
the "type" and the name saved) in order to facilitate proper checking of variable 
argument or parameter lists. In this way, if the name is bound within the actual 
arguments or parameters, it is determinable which formal argument or parameter 
is associated with that name. 


2. Model. 

Based on these requirements, a design was developed that provided an efficient 
solution. The cornerstone of this design was the means in which a signature lookup was 
accomplished. The best solution this research found was to have a map from a name toa 
set of tuples. Each tuple in this set represents one distinct overloading of the name in the 
domain of the map. By searching this set of tuples, the specific overloading which is 
being used can be found. 

To provide an efficient means for information lookup, each tuple in this set 
contains a list and a number. The list is an ordered list of tuples and each tuple in the list 
contains information on one of the formal arguments in the signature. The number is a 
value or cross reference that when "looked up" in the symbol table provides immediate 
access to all information concerning that symbol. 

The tuple representing one of the formal arguments or formal parameters consists 
of two elements--the name of that element and its "type". The "type" that is placed in 
this second element is derived from a map which has a domain consisting of all the types 


that are visible at that point and a range consisting of a translated text for that specific 
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type. The translated text is simply a modified version of the actual type name. If a type 
name belongs to a concept, it 1s local to the current module, so an "@" symbol is 
appended to the name followed by the current module’s name. If the type name belongs 
to a module, the range matches the domain. In this way, if a concept is defined 
differently in two different modules the "relationships" (e.g., messages, etc.) between the 
modules must use the concept they were defined with and not the corresponding concept 
in the other module. In Figure 3.2 the two types of entries permitted in the "type" map 


and the module that defines them are shown. 


TYPE complex 
MODEL (re: real, im : imaginary_part) 
INVARIANT 


CONCEPT imaginary_part : type 
WHERE imaginary_part = real 
END 


Translated equivalent. 
complex 


imaginary_part@complex 





Figure 3.2 
Limiting Type Visibility. 


Based on these features, the symbol table becomes a map from the cross reference 
value to a tuple. This tuple contains the required information for each symbol, its 
parameters, Class, textual name and type. The parameters element is a tuple which 


represents the formal parameters (if any) of the symbol. The class element contains some 
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representation of the class (function, message, concept, etc.) that the symbol belongs to, 
and the textual name element contains the actual text of the symbol (used for error 
reporting). 

While determining the conceptual model of the last element of this tuple, it was 
noted that each symbol that would be placed in the symbol table was either a variable, a 
concept or message or a module name. Interestingly enough, this indicated that the type 
element of the tuple contained in the domain could have a dual purpose. If the symbol 
was a variable or "non-function" concept (a concept without a VALUE clause), the actual 
type of that name could be placed in that field. If the symbol is a message or concept 
with a VALUE clause, the type that the symbol returns could be placed in that field; and 
if the symbol was a module name, no information needed to be placed in that field. 

Actually building these tables presented another problem. Due to the declaration 
requirement that a module name could not be redeclared and that concept and message 
names are visible throughout the entire module they are defined in, the- necessary "name" 
table has to be built in three “layers”. In the first layer, all of the module names are 
collected into a table and any redeclarations are identified. These module names are then 
passed down into the second layer during which all message and concept names are 
added to the table. Additionally, if a message has an operator associated with it, the 
operator can be treated as a name unto itself, with the same arguments as the message 
and stored in the table accordingly. 

When this table is returned to the top of the semantic tree, one additional level of 


indirection is added to it so that a name declared in one module doesn’t "overwrite" the 
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identical name declared in a different module. This level of indirection is added by 
taking the original map and making it the range of a new map whose domain is the 


module name. Figure 3.3 shows this process. 


before: string -> string 


after: |module_name -> string -> string 





Figure 3.3 
Localizing a Map. 


The final layer in the name analysis process takes this table produced by the 
second layer and "cuts" it within each module so that only those names defined in that 
module are passed back down. All other names that are encountered within that module 
are then added to it, according to the scope rules of the SPEC language. With the tables 
being "manuevered” through the semantic tree during this layer, the type consistency 
analysis can be performed. Additionally, if the tables produced by the second layer are 
passed down the tree also, these tables can be used to verify whether a message exists or 


doesn’t exist in another module. Figure 3.4 demonstrates this name layering process. 


Contains Structure 
nothing, yet. name -> tuple 


module names name -> tuple 


modules, concepts, messages module name -> (name -> tuple) 
modules, concepts, messages name -> tuple 


this map only has locals. 





Figure 3.4 
Name Layering. 


With these tables, the type consistency analysis simplifies to two distinct parts. 
The first part involves obtaining the correct symbol from the tables produced in the 
layering process. To determine that only one unique possibility exists for this symbol, 
both of the layer three tables must be searched--the local table and the table which 
contains all the symbols defined in other modules. However, in the second table, only 
messages need be examined. 

The second part of the type consistency analysis involves checking the actual type 
of the symbol. Ideally, this should only be a "lookup" in the symbol table, but since a 
message or concept may have a value that is transitively dependent on another message 
or concept,a routine that recursively resolves the type must be performed. Figure 3.5 
shows a two dimensional transitive dependency situation. The first message, message_]l, 
has a resultant value that is dependent upon a concept, dimension_2. Theoretically, this 


transitivity could be repeated extensively. 


MESSAGE message_1(... ) 
REPLY dimension_2 (... ) 


CONCEPT dimension_2 (... ) 
VALUE (... ) 





Figure 3.5 
Result Values Transitive Dependency. 


To conclude the process, the type is passed up to the next higher level of the 
semantic tree and used to resolve that level. Additionally, any errors encountered are 


concatenated onto the error messages from the "children" of the current level and also 
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passed up. When the uppermost level of the semantic tree receives these error messages 
from its children, the type checking process is completed and the errors can be reported 


to the user. 


C. DESIGN CONVENTIONS. 

In an effort to increase the readability of the source code, it was decided that the M4 
macro preprocessor would be used and a stardardized attribute naming schema adopted. 
The attribute naming schema assisted in cutting down the source code size, but the M4 
macro preprocessor helped significantly more. The M4 preprocessor "shrunk" the actual 
code size almost 50% (3926 lines prior to expansion, 7591 after) by coalescing multiple 


source code lines into one line of M4 code. 


1. Attribute Naming. 

The primary rule followed in the naming of all attributes was to make the name as 
descriptive as possible concerning the purpose of the attribute, without “exploding” the 
size of the source code. Additionally, each attribute is appended man an underbar (_) 
followed by a descriptive character (s or 1) which signifies the use of the attribute 
(synthesized or inherited). Some sample names include "module_name_s”, 
“visible_types_i’ and "“ip_stbl_s". A complete listing of all descriptive names is 
contained in Appendix D. 

Certain abbreviations were adopted to assist in the naming, without making the 


name too long. Some of the more common abbreviations include: 
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ip : signifies that the attribute is currently “in the process” of being built. The 
information currently contained in this attribute is not reliable for any other purpose than 
building the final attribute and thus should not be used for any other purpose. 

Iclzd : denotes that a table is "localized". A localized table is normally a map 
with a domain consisting of a string and the range containing another map. The string in 
the domain string will always be a module name or a scope related value (such as 
"GLOBAL_TYPE_NAMES" in myconst.m4). 

stbl : symbol table. Any attribute name prefixed by this word denotes an attribute 
that is part of the symbol table group of attributes (e.g., stb]_names). 

xref : cross reference. Any attribute containing this abbreviation has a range 
which contains cross reference information in it (normally within a tuple). Many times, a 
prefix is appended to this word (mxref or mcmxref) to assist in the distinction of the 
attributes’ purpose. Two of the more common attributes using this abbreviation are 
mxref (module cross reference) and mcmxref (module-concept-message cross reference). 

env : environment. This abbreviation is commonly used in attributes that are 
passed down to non-terminals to "inform" the non-terminal of the environment within 
which it is currently being utilized. 

2. M4 Macro Abstractions. 
The actual M4 macro definitions are contained in three different files-- 


“attrib_psg.m4", "mymac.m4" and "myconst.m4". Two additional M4 files were used in 
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this design (head.m4 and tail.m4) but they simply contain certain M4 commands that are 
required so that M4 will function properly with the Kodiyak tool. All of the M4 files are 
enumerated in Appendix 2. 

a. Attrib_psg.m4. 

This file contains all the M4 macros that are associated with a general 
attribute passing capability. They could be used in any Kodiyak program and are not at 
all specific to the type checker. Most of these macros have been derived from the 
“macros.m4" file developed by Robert Herndon and promulgated with the Kodiyak 
compiler. Some modifications were made to the actual definitions for the purpose of 
standardization, however. Most of these modifications involved changing a macro’s 
name to more accurately reflect how many attributes were being passed and how many 
non-terminals these attributes are passed to. 

There are six actual groups of macros within this file. Each group is 
characterized by a descriptive name, followed by two integer values separated by an 
underbar. The name details the purpose of the macro and the integer values represent the 
number of non-terminals being passed followed by the number of attributes affected 
(e.g., passio2_4--pass in order to two non-terminals, four attributes). The arguments for 
the macro follow in the same order as the integer numbers--non-terminals first, then 
attributes. The six names used for these macros are: 

Passup : Pass up an attribute from a child non-terminal ($1, etc.) to the parent 


non-terminal ($$). Figure 3.6 graphically depicts this class. 
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Parent Non-terminal. 


Child Non-terminal 





Figure 3.6 
Passing Up an Attribute. 


Passdn : As shown in Figure 3.7, an attribute is passed down from the parent 


non-terminal to child non-terminal(s). 


Parent Non-terminal. 


Child-1 Child-2 Child-3 Child-4 Child-n 





Figure 3.7 
Passing Down an Attribute to "n" Non-terminais. 


Passovr : Figure 3.8 shows how this macro "passes over" an attribute from 
one non-terminal to another. There are two variations of the passovr macro. The first 
variation 1s simply a "“passovr" from one non-terminal to another (passovr_l). The 
second, which is a logical extension of the first, passes the specified panies of attributes 
to more than one non-terminal from only a single non-terminal. To vividly display this 
significant difference from the weave and passio macros, the naming of this variation is 
slightly different from the standard naming. An "x" was placed between the first integer 
(signifying number of non-terminals) and the underbar. The "x" is best interpreted as a 
"times". Thus, the macro looks like "passovr2x_1" which means "passovr two times, one 


attribute”. 
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Parent Non-terminal. 


Child-1 Child-2 Child-3 Child-4 





Figure 3.8 
Passing Over an Attribute to “n"’ Non-terminals. 


Passio : Pass an attribute in order from the parent non-terminal, through the 
specified children non-terminals and back to the parent. Figure 3.9 shows this commonly 


used macro. 


Parent Non-terminal. 


(N'Y 


Child-2 Child-3 





Figure 3.9 
Passing an Attribute In order to "n" Non-terminals. 


Weave : Weave an attribute from a child non-terminal, through other 
specified children non-terminals and into a non-terminal. As shown in Figure 3.10, this 


macro is similar to Passio, except the parent non-terminal is not affected. 


Parent Non-terminal. 


[ 
Child-1 Child-2 Child-3 Child-4 Child-n 





Figure 3.10 
Weaving an Attribute to “n" Non-terminals. 


cat...up : Concatenate "..." up to the parent non-terminal from the children. 


The "..." may be either the abbreviation "str" meaning string or "map" meaning map. 
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b. Mymac.m4. 

This file contains macro definitions that are unique to the type checker. Each 
of these definitions provides a shorthand method of expressing multiple lines of Kodiyak 
code and greatly simplifies the readability of the source. They can be logically divided 
into three groups. 

(1) Declaration Group. 

The declaration group consists of four different macros, which are used in the 
attribute definition section of the Kodiyak source. They are designed to make each non- 
terminal’s defined attribute list more readable. 

(2) Symbol and Visibility Tables Group. 

These macros are defined to assist in the attribute evaluation section of the 
Kodiyak source. They primarily provide simple statements for passing the symbol (or 
visibility) tables down from one non-terminal to another. 

(3) Attribute Evaluation Group. 

This group of macros is also used in the attribute evaluation section of the 
Kodiyak source. They simplify the amount of code used to express the equations to 
“make a declaration”, etc. 

c. Myconst.m4. 

This M4 definition file contains the various symbolic constants used 
throughout the Kodiyak source. Some slight variations of these constants are also used in 
the C language file mylib.c and the correlation between them is vital to the type checker. 


All relationships are detailed as comments in the mylib.c file. 
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TV. IMPLEMENTATION. 


A. SEMANTIC INFORMATION STORAGE STRUCTURES. 

To properly type check the SPEC source code, various tables were required. These 
tables contained information relevant to each module, such as message names, 
arguments, parameters and result types. The primary requirement that necessitated the 
use of these tables was the "non-block" structured nature of certain SPEC constructs. For 
example, when the information regarding a specific message is looked up, a "match" 
must be searched for in the current module and all type modules corresponding to an 
argument type of the message. These type modules may or may not have been 
previously declared. Another of the non-block structured SPEC structures is the fact that 
concept names are visible throughout the entire module in which they are enclosed, thus 
requiring, at the very least, that the module be "passed over" twice--once to obtain the 


information about concepts, and the second time to type check the rest of the module. 


1. Module Types. 
The module types table contains a listing of all the valid type names that are 
visible in a module that must be accessible immediately upon entering the module (e.g., 
concepts and module types). This table is especially important due to the fact that all 


other tables depend upon it. Whenever a type is stored, its "translation" in this table is 
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used, vice its actual name. The translation represents a globally unique name for the 
type. This permits the localizing of types that are truly local to the module such as 
concepts. 

The table is structured as a map from strings to a map of strings to strings. The 
domain string consists of the module name, the domain string of the range map 
containing the actual name of the type (e.g., real) and the range string containing the 
translation that will be used to reference the type. To symbolize local names, the current 
module name is prefixed by an "@" symbol and the actual local name 
(local_name@ module_name). 

One of the most important uses of this table is to select appropriate portions (or 
“cuts") from it when a module is entered, and place these "cuts" in the visible types table. 


This table is then used throughout the module. 


2. Symbol Table. 

Due to the lack of tuple structures in the Kodiyak language, the symbol table 
actually consisted of five different tables. Each of these tables has a unique purpose. 
The primary table, called the symbol table, consists of a map from strings to a map 
consisting of strings to strings. The primary domain of the map contains module names. 
The domain of the "range map" consists of the symbol’s name and the range of this map 
contains a group (or variant tuple) of patterns. Each pattern is separated by a delimiter 
(PATTERN_DELIMITER). 

A pattern is a tuple consisting of a variant sized tuple of formal or actual 


arguments, and a cross reference value. Each element in the formal or actual arguments 
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"subtuple” is separated by a delimiter (ELEMENT_DELIMITER) and this subtuple is 
separated from the cross reference value by another delimiter (CREF_DELIMITER). 
Figure 4.1 shows the format for a pattern and a pattern string. In this Figure, the 
ELEMENT_DELIMITER is represented by +, the XREF_DELIMITER by @ and the 


PATTERN_DELIMITER by ¢. 


pattern 
arg) °args*arg3¢ ... arg, #xref_value 


pattern string 
pattern, ¢pattern? ¢ pattern3¢ ... pattey 





Figure 4.1 
Example of a Pattern 


The cross reference value is of extreme importance to the type checker. It is used 
in the rest of the maps which contain the symbol table information to access the 
information. Without this cross reference value, much of the information required could 


not be accessed properly. 


a. Textual Names. 
This 1s the first table containing the symbol table information, other than the 
actual symbol table. Its structure is a map from integers to strings. The domain of the 
map contains the cross reference value and the range contains the actual text of the name 


of that symbol. This information is commonly used in error messages. 


b. Parameters. 
This table contains the formal parameters associated with a symbol. Its 


Structure is a map with a domain of integers and a range of strings. The domain is the 
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cross reference value of the symbol and the range is a string consisting of a concatenation 
of all the parameters of the symbol and their types. Each element in this concatenation is 
separated by a delimiter and within each element, the element’s name and its type are 


separated by a different delimiter. 


c. Results. 

The results table is a map from an integer cross reference value to a string 
which contains the result type of the symbol. A result type can be interpreted in two 
different ways. In the case of a message or concept with a VALUE clause, the result type 
contains the type of the reply or value. If the symbol is a variable or variable-type 
concept, the result type contains the type of the vanable. 

Since the result table must be built prior to its use in the actual type 
consistency checking, if the type to be placed in the table is a message or concept call, 
the actual text of the message or concept call is prefixed by a special symbol, which I call 
the reference symbol, and placed in the range of the map. This presents the requirement 
that a C language function be used to assist in resolving the type of any construct, since 
this result table value may be transitively dependent on other values. This C language 
routine, which I have named "Resolve_Type", will recursively analyze the result types of 
different symbols until a result type is found that is not preceeded by the reference 


symbol. 


d. Classes. 
This table is used to uniquely identify the classes of various names. It is 


extremely important and allows checking of a name to determine if it is a message, 
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module, concept or variable name. Each different class has a unique value and these 
values are detailed in the file "myconst.m4", which is listed in Appendix B. 
3. Visibility Tables. 

The two visibility tables used by the type checker address the block structured 
constructs in the SPEC language. They are initially constructed in a module’s interface 
and then passed into the various other parts of the module. These tables are then added to 
and passed into additional non-terminals based on the scoping rules of the variables in 
SPEC. 

a. Visible Types. 

The visible types table is constructed initially from the module types table. In 
the module’s interface, all types corresponding to the module’s name are extracted from 
the module types table and placed in the visible types table. This table is then passed into 
all the other non-terminals in the program, as dictated by the scope rules. The visible 
types table is not added to by concept names since these names are already in the table. 
Any other types that are declared (in variable names) are added to the table. This table is 
used to build any table requiring a type. The value of this type could be localized or the 
actual name as discussed above. 

b. Visible Names. 

The visible names table is initially formed in the interface section of a 
module. Currently, it is primarily used in the name declaration routines to determine if a 


name is already declared. It will also be used extensively in the type checking routines to 
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obtain the cross reference value of a symbol when that symbol is used. As done in the 
visible types table, it is passed to all non-terminals as dictated by the scoping rules of 


SPEC. 


B. MAJOR ATTRIBUTES. 


1. Error Reporting. 

Errors are reported in SPEC in one of two ways. If the error can be identified by 
the attribute grammar equations, a call to the C language function "error_message” is 
made. This function returns a string in the correct format for an error message and 
contains the appropriate information. If the error cannot be identified by the attribute 
grammar equations, but can be identified by a "C" routine, that C language routine may 
call the error_message function directly. 

a. verror_message. 

The verror_message function is the actual C language function corresponding 
to a call to “error_message” in the attribute grammar equations. It is contained in the 
mylib.c file and detailed in Appendix B. All of the codes for error messages are a 
constant integer value and are detailed in the file myconst.m4 and mylib.c. Each error 
has a unique code. Each code has a predetermined number of arguments that it requires 
to properly report the error. When the error in "invoked", all of these arguments must be 


passed to the verror_message function in the correct order. 


b. Declaration Errors. 
Declaration errors are determined by two different C language functions-- 


"“vcheck_simple_decl" and "vcheck_complex_decl”. The first of these routines, 


ai 


check_simple_decl, is used to check all declarations that do not have a signature of 
arguments associated with them. The second routine, check_complex_decl, is used for 
declarations that have a signature. Each of these functions returns a null string if the 
declaration is not previously defined or an error message otherwise. All of the 
declaration errors are placed in an attribute named "d_error_s". Prior to adding the 
current declaration to the respective table, this attribute is checked and if it is NULL, the 


attribute is added. 


c. Error Concatenation. 
All errors are passed up the semantic tree in an attribute named error_msgs_s. 
Each non-terminal in the tree has this attribute associated with it. At each level, the 
attributes are concatenated with the lower levels and any errors that were discovered in 


that level and passed up to the higher levels. 


2. Building the Symbol Table. 

As mentioned above, the symbol table actually consists of five structures, each 
structure having a unique purpose. It was determined that the four secondary tables 
(textual names, parameters, results and classes) could be built independent of the primary 
table (stbl) since these tables depend only on the cross reference value which can be 
determined immediately. 

The pnmary table (stbl) 1s built in two layers, due to the declaration precedences 
of SPEC. These precedences require that module names be globally visible and unique, 
and messages and concepts be unique within their module. Therefore, the first layer of 


the symbol table building process collects all the module names and passes them up to 
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the root non-terminal (in the "ip_mxref" attribute). These names are then passed back 
down the semantic tree (as the ip_mcmxref attribute) and all the message and concept 
names are collected in accordance with the scope rules of SPEC. In this way, 
redeclarations are reported in a logical, semantically correct order. For example, if a 
message or concept name redefines a module name, an error is reported when the attempt 
is made to define the concept or message name. After this primary table is built, it is 
passed down into all non-terminals and used to construct the visible names table in the 
interface section of each module. 

The other four parts of the symbol table are built in one layer. This layer collects 
all the values and their appropriate range and passes the results up so that they can then 


be passed back down and used by all the non-terminals. 


3. Extended Types. 

Due to the need to store result types in a result type table, it was necessary to 
develop a slightly modified type called extended type. If a type is immediately 
determinable, such as a literal or type name, the range of the visible_types table for the 
actual type name is placed in the "xten_type” attribute. If the type of the construct is not 
immediately determinable, the actual text of the construct is placed in the attribute. In 
this way, aC language function, resolve_type, can take this value and resolve the type of 


the construct or symbol when needed. 


C. NAME ANALYSIS. 
Name analysis is the first of three aspects in the type checking process. During name 


analysis, tables are built reflecting all the names used in the SPEC code. If an invalid 
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declaration is attempted or an invalid type used, an error is reported. The tables built 
during name analysis are used during the second aspect (type consistency checking) to 


determine if any errors occur. 
1. Checking if an identical declaration exists. 

There are two routines used to check if a declaration exists prior to declaring a 
name--check_complex_decl and check_simple_decl. Each of these routines takes a 
signature and analyzes all other symbols in the current scope to see if that name has been 
previously declared. If it has, they will report an error, otherwise, they return a NULL 
string. 

2. Making a new declaration. 

To make a declaration, three macros were defined in the "mymac.m4" file. Only 
one of these macros need be used. Each of them checks a string type attribute (always 
named d_error_s) and if that attribute is NULL, makes the declaration. If the attribute is 
not NULL, meaning that the declaration would be a "redeclaration”, the declaration is not 
made. 

3. Reporting an error. 

An error is reported at the declaration point as detailed in section 1 above. In 
each non-terminal structure that declares a new name, the attribute "d_error_s” is 
concatenated with all other error messages from the children non-terminals and the result 
is passed up the semantic tree. In this way, the errors encountered are placed in the 


correct position within the list of error messages. 


D. IDENTIFYING ERRORS TO THE USER. 

The third and final aspect of type checking reports any errors that occured to the user. 
Currently all errors are identified by SPEC source line numbers. If no syntax errors 
occur, these error messages are output to the standard output at the end of program 
execution. Currently, the SPEC grammar does not have syntactic error productions 


added in, although they have been developed for previous versions of the grammar. 
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V. EXTENSIONS. 


A. TYPE CONSISTENCY ANALYSIS. 
Type Consistency analysis is the second aspect of the type checking process. 
Although the C language routines were coded and syntactically debugged, the required 


attributes have not been implemented into the Kodiyak source code. 


1. Seeking the Correct Symbol Table Entry. 

The process of finding the correct symbol table entry is similar to that of checking 
to see if a declaration has been made, except for the fact that actual arguments instead of 
formal arguments are included in the "source" name. To obtain the correct symbol table 
entry, a call is made to the C language routine "seek_symbol”. This routine will search 
the current environment (visible_names), and the global environment (stbl) to determine 
if the name exists. If more than one possible interpretation of the name exists, the 
function will return the appropriate error message, listing all possible interpretations. If a 
unique candidate exists for the signature, the string representation of the cross reference 
value of the symbol is returned. Conversely, if no symbol could be found that matches 
the signature passed to seek_symbol, the string representation of the integer value "O" 
will be returned. If desired, this routine could be easily modified to allow an error 


message to be returned if no symbol exists. 


2. Obtaining a Symbol Table entry’s type. 

If a symbol has been found that matches the actual name of the symbol, another 
"C" language routine, "resolve_type" is called to obtain the result type of the symbol. 
Using the information provided in the "stbl_results” table, this routine recursively 
analyzes the symbol’s value until a valid type name is obtained. The recursive analysis is 
required to resolve this table’s transitive dependency on other messages or concepts as 
discussed in Chapter 3. When this transitive dependency is resolved, the type name’s 
translation in the "visible_types" table is returned to the Kodiyak attribute. This attribute 
is then passed up the semantic tree and used at "parent levels" to determine if an 
operation is valid. 

3. Determining if an Operator is defined. 

During the name analysis, an entry was made in the symbol table for each 
operator overloading. Since SPEC is entirely defined in terms of the standard type 
library, by processing the standard type library together with the SPEC code to be type 
checked, all possible operator meanings are placed in the symbol table. To determine if 
an operator use is valid, simply take the operator’s textual representation, append the 
appropriate arguments (determined by its use) to it and use the routine "seek_symbol". 
This routine will then return the cross reference of the message that overloaded that 
operator. Then the result type may be obtained as discussed in section 2 above. 

4. Reporting Errors. 
The reporting of type checking errors is very similar to the reporting of 


declaration errors with one small exception. Since “seek_symbol" always returns a string 
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value, the attribute in which this value is stored must be checked to see if the attribute 
contains an error message or the String representation of an integer (greater than 0). If 
the attribute contains an error message, that error message is then concatenated with the 
error messages generated by the children non-terminals and the result passed up the 
semantic tree. Otherwise, only the error messages generated by the children are 


concatenated and passed up the tree. 


B. SPECIAL SPEC LANGUAGE ISSUES. 

Some of the more complex SPEC issues such as inheritance, instance declarations 
and importation/exportation were addressed and accounted for in the design, but not 
implemented. The proposed methods for implementing these features, based on the 
design is discussed below. 

1. Inheritance & Instance Declarations. 

Inheritance and instantiation present unique challenges to the generation of a type 
checker using an attribute grammar tool. One of the most significant problems arises 
because of the possible transitivity of either of these structures. For example, a module 
may inherit a module which inhents another module, which inhents another module, etc. 
This requires that the module which is the "lowest common denominator” be expanded 
first, then the next, etc. 

Additionally, the way that inheritance is defined in SPEC poses other problems. 
Specifically, if a module inherits another module which contains a message with the 
Same signature as the current module, the two messages are combined according to 


predetermined rules [Ref. 20] to form the expanded, resultant module. 


a. Preprocessor Usage. 

To address these unique problems, this thesis proposes the use of a 
preprocessor. This preprocessor would take the SPEC source code, expand it as 
necessary and present its output to the type checker. The type checker would then 
Operate upon this intermediate source code and produce its error messages. If the 
"inheritance / instantiation tool" recognized any errors such as a circular inheritance, it 


would report these errors to the user and terminate. 


b. Error Reporting Drawback. 

The preprocessor would present to the type checker a modified version of the 
source code with no inheritance or instantiation (and probably write its output to a file). 
This however, presents a problem. Since the type checker reports error messages based 
on a source code line number, any errors identified would be associated with a line 


number relating to the "expanded" source, not the original SPEC source code. 


c. Potential Advantages. 

This methodology may have its advantages, however. If the process of 
inheritance introduces a structure that has semantic errors in it, the error could be looked 
up in the output of the inheritance tool and traced back to its onginator. Also, with the 
advent of sophisticated text processing tools for the SPEC language, it may be possible to 
edit the "true source” code in one window while viewing the error in another window. 
Another implicit benefit may be that software developers could use the inheritance tool 
independently to examine the expanded specification to determine if they have "hidden" 


or "renamed" everything as appropriate. 
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2. Importation & Exportation. 

One of the final issues addressed in the design was importation and exportation. 
Although they are two different constructs in SPEC, they are uniquely related--a concept 
may not be imported unless it is exported by the module in which it is defined. 
Additionally, importation and exportation do not present any of the problems posed by 
inheritance. They are not transitive and if a concept is already defined with an identical 
signature, the new concept cannot be imported and an error should be reported. 

The way in which the design was built presents a simple solution to 
importation/exportation. Initially, a new structure (lclzd_exportables) must be built. 
This structure should be a localized map with a domain of strings and a range which is a 
map. This domain string would contain the name of the module as in all localized maps. 
The map which makes up the range should be a map from string to integer. It would 
contain as a domain the name of the concept, and as a range an integer value (0 or 1) 
representing the boolean value true or false. The range would be true if the concept is 
exported, false otherwise. 

The second part of the solution is when an importation is requested by a module, 
this new table (Iclzd_exportables) is checked immediately. If the module does not export 
the desired concept, an error should be reported. Conversely, if the desired concept is 
exported, the "visible_names" table would be augmented with the signature and cross- 
reference information of the concept(s). This augmentation process would require a C 
language function which processes the domain of the "stbl" structure for the specified 


module and name and then returns a string consisting of all the new patterns (signature 


and cross reference information) which are to be added. This routine would have to be 
passed the "stbl_classes" structure so that it could verify that the symbols that it returns 


are indeed concepts and not messages. 


C. IMPROVED ERROR REPORTING. 

The type checker currently reports declaration errors in a way that is easy to 
understand, but sometimes difficult to find the conflicting declaration. In order to 
provide better feedback to the user, additional tables could be added to the symbol table 
to promulgate information that would assist in error reporting. For example, a table with 
a domain containing the cross reference value and a range containing the line number 
where that symbol was declared would enable error reporting to report the location of a 
conflicting declaration. 

Another error reporting difficulty is that some of the SPEC constructs have WHERE 
clauses that require dynamic (run-time) evaluation. Although it is not feasible to 
automatically check these clauses, it is recommended that a warning message or pragma 
be output listing the where clause’s contents so that the user could examine this to ensure 


the validity of the specification. 


D. SUBTYPES. 

Subtypes in SPEC are defined as concepts and have a WHERE clause associating the 
concept name and another defined type. They present a slight problem because, like 
inheritance or instantiation, a subtype may be transitively dependent on another subtype. 


The solution to this problem involves using two C language routines, one for declaring a 
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subtype and one for analyzing it. The first routine, “declare_subtype" would take the 
subtype name and the type which it is a descendant of and place it in a table. The second 
routine, "is subtype" would then take a type name and recursively analyze this table, 
retuming a boolean value representing the validity of the subtype. This routine 
"is subtype" could then be used in some of the existing C language routines such as 


“type_equivalent" to assist in the determination of type conflicts. 


E. VARIABLE ARGUMENT OR PARAMETER LISTS. 

The implementation of variable argument or parameter lists (list preceded by a ’$’) is 
an interesting proposition. Since there are many diffent ways in which these lists may be 
fitted together, a recursive analysis is required. Currently, variable argument lists have 
been acknowledged, but the required recursive analysis has not been implemented. This 
analysis should take place in the routines that check a declaration and seek a cross 


reference. 
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VI. CONCLUSIONS. 


A. INTEGRATION INTO A PROGRAMMING ENVIRONMENT. 

To truly provide the SPEC user with an effective software development tool, the type 
checker must be integrated into a programming environment. In addition to a type 
checker, this environment should contain at least a syntax directed editor, pretty printer, 
test case generator and eventually a translator that will translate a significant part of the 
specification into a compilable target language. 

In the short term, the type checker, syntax checker, inheritance preprocessor and 
pretty printer should be able to work together in a way that makes the actual separation of 
these tools transparent to the user. This could be accomplished efficiently by writing a 
unix command script that begins a tool execution when the previously running tool (if 
any) completes. In this script, the syntax checker, inheritance preprocessor and type 
checker should be called in sequence to provide the user with syntactic and semantic 
information concerning their program. Additionally, at least two options should be 
provided with this script. One option would allow the user to retain a copy of the file 
containing the specification after it has been expanded by the inheritance preprocessor 
and the other would run the pretty printer on the code if it is semantically and 


syntactically correct. 
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B. EVALUATION OF THE TYPE CHECKER. 

Although the type checker is not as yet a usable tool, its feasibility has been 
researched and a solid groundwork has been laid for the rest of the implementation. 

1. Kodiyak Deficiencies. 

While researching this thesis, many deficiencies and "bugs" were found in 
Kodiyak. The primary deficiency was the lack of any types other than integer and string. 
The implementation of the type checker was forced to use many identical data structures 
for similar purposes that should have been one structure. Specifically, the symbol table 
required by the SPEC language necessitates the use of a tuple in the range. Since there is 
no tuple type in Kodiyak, four maps were used to contain the information. 

The inability in Kodiyak to declare a global variable also presented a problem. 
Ideally, since the symbol table is not modified once it is built, it would be convenient 
(and conserve memory space) if this table could be placed in a variable or data structure 
that could be referenced from every production. In this way, fewer attributes would have 
to be passed down the semantic tree and the number of attribute equations would be 
decreased. 

The lack of documentation in the Kodiyak C library is a substantial drawback. 
Since Kodiyak is entirely implemented in terms of other tools, the handling of strings and 
integers is defined in the C language and utilized by the Kodiyak processor as function or 
procedure calls. To effectively extend Kodiyak so that it could meet the requirements 
dictated by SPEC, many long hours of deciphering the source code and experimenting 


was required. 
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The lack of any predefined Kodiyak functions to output the contents of an entire 
map is a handicap. During the incremental implementation of the various maps that 
make up the symbol table, it was necessary to output the information they contained to 
verify the functioning of the attributes. Unfortunately, the only way to accomplish this 
task was to select each individual map entry and display it. After a short while, this 
became very tedious and so routines were built and debugged that dump one dimensional 
maps. 

2. Kodiyak Benefits. 

Probably the most beneficial feature of Kodiyak is its ability to preprocess M4 
files prior to conducting the Kodiyak scan. When the preprocessor is extensively used 
and considered throughout the implementation, the source code size can be shrunk 
dramatically, making both the programmer’s and reader’s job easier. Additionally, the 
M4 macros defined by Robert Herndon proved to be invaluable. 

Another positive feature of Kodiyak is the way it integrates the functioning of 
Lex, Yacc and the C Compiler to produce an executable product. Since all of these tools 
are reasonably well understood, many of Kodiyak’s functions can be analyzed from 
another perspective, providing an alternative approach to debugging. 

Kodiyak’s C language interfacing ability, although difficult to decipher initially, 
proved to be a benefit in the long run. It provided a way to “work around" the 


deficiencies and implement the type checker in an efficient, sensible manner. 
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C. FUTURE WORK. 


1. Extensions of the current implementation. 

The type checker is feasible and worthwhile to complete. The extensions sull 
required are implementable by two students, working independently and present no 
significant problems. One student should focus effort on the preprocessor and another on 
implementing type consistency checking, importation and integrating a current version of 
the error productions into the type checker. 

Since the design and implementation of this thesis, the meaning of a signature has 
been extended to include the formal parameters of modules, concepts and messages. To 
implement this feature, the type checker’s implementation of a "pattern" must be 
extended to include formal parameters by adding in a new delimiter and the additional 
information. All of the C language routines which check declarations and look up names 


must also be extended accordingly. 


2. Incremental Type Checking. 

One significant project that should be addressed in the future is the incremental 
type checking of the SPEC grammar within a syntax directed editor. This would then 
allow any errors to be identified concurrently with the wniting of the specification, 
permitting better time utilization. Additionally, the benefit for individuals learning the 
SPEC language would be significant since as syntax or semantic errors were made, the 
reason and cause would be displayed immediately. A syntax directed editor for SPEC 


currently exists [Ref. 21]. 
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D. GUIDELINES FOR EXTENDING KODIYAK. 

The Kodiyak language is very simple to extend when the interactions between the C 
library and the actual Kodiyak tool are understood. These interactions are manifested by 
calls to functions in the C library which are built through strings in the actual Kodiyak 
AG code. For example, a Kodiyak language map reference translates into a call to one of 
six map lookup functions, depending on the domain and range of the map. Some 


guidelines for using the C language escape feature of Kodiyak are: 


e Whenever a string is used directly from the Kodiyak program, the string should 
be immediately "flattened" to the temporary work area (by means of a call to 
xtstrflatten) and then IMMEDIATELY copied to a work area belonging to your 
routines. Leaving a string in the Kodiyak temporary work area can be fatal since 
Kodiyak overwrites that work area frequently. 


e Always build in extensive error checking in your routines to avoid errors such as 
array overflow. "Silent" errors in your routines may cause other, reportable 
errors within Kodiyak which may confuse the situation. 


e Syntactically debug your routines independently from Kodiyak (as best as 
possible) to avoid unnecessary (and frustrating) delays. The Kodiyak 
compilation process is not fast by any means--especially the C compilation 
phase. 


e The Kodiyak program prepends a "w" to the name of a routine beginning with a 
"9" (e.g. a procedure) and a "v" to the name of any function before calling that 
function in C. 
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APPENDIX A - SPEC GRAMMAR. 


This Appendix contains the version of the SPEC grammar used to implement the type 
checker. This version does not contain any of the syntactic error productions which have 
been developed or any attribute definitions. It is primarily provided as a quick reference 
for the grammar of the SPEC language and for contrast with the type checkers attribute 


grammar code which is contained in Appendix B. 


version stamp $Header: spec.k,v 1.10 89/02/11 20:11:31 berzins Locked $ 
Kopas Version -- Updated to version 1.11 of grammar 20 April 89. 

In the grammar, comments go from a "!" to the end of the line. 
Terminal symbols are entirely upper case or enclosed in single quotes 
Nonterminal symbols are entirely lower case. 

Lexical character classes start with a captial letter and are enclosed in {}. 


(‘). 
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In a regular expression, x+ means one or more x's. 
In a regular expression, x* means zero or more x’s. 
In a regular expression, [xyz] means x or y or z. 
In a regular expression, [*xyz] means any character except x or y or z. 
In a regular expression, [a-z]) means any character between a and z. 
In a regular expression, . means any character except newline. 
! definitions of lexical classes 
define Digit : (0-9) 
$define ligne s({Digat}+ 
define Letter : [a-zA-2]) 
$define Alpha :({Letter})|({Digit}{i*" ™) 
tdefine Blank Fae oo! 
tdefine Quote a3) 
tdefine Backslash ie a 
tdefine Char 2((*"\\) t{Backslash} {Quote} |{Backslash} {Backslash}) 
1 definitions of white space and comments 
:{Blank}+ 
27 s\n 
! definitions of compound symbols and keywords 
AND iat Sail 
OR Ric lias 
NOT .nan 
IMPLIES .r=> 
LFF 2tc=> 
LE ak ed 
GE ee >=" 
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NE 
NLT 
NGT 
NLE 
NGE 
EQV 
NEQV 


RANGE 
APPEND 
MOD 
EXP 


BIND 
ARROW 


Le 
THEN 
ELSE 
IN 

U 


ALL 
SOME 
NUMBER 

SUM 
PRODUCT 
SET 
MAXIMUM 
MINIMUM 
UNION 
INTERSECTION 
SUCH 
ELSE_IF 


AS 

CHOOSE 
CORCEPT 
DEFINITION 
DELAY 

DO 

END 
EXCEPTION 
EXPORT 

Es 
FOREACH 
FROM 
FUNCTION 
GENERATE 
HIDE 
IMPORT 
ENHER IT 
TNITIALLY 
INSTANCE 
INVARIANT 
MACHINE 
MESSAGE 
MODEL 

OD 

OF 
OPERATOR 


1D 


:{Backslash} |MOD 


Rex 


raga 6 
; THEN 
See, 
3 IN 
2U 


:ALL 

> SOME 

: NUMBER 

>SUM 

PRODUCT 

vod 

:MAXIMUM 
:>MINIMUM 

>: UNION 

: INTERSECTION 

>: SUCH {Blank} *THAT 
:ELSE{Blank}*IF 


:AS 

: CHOOSE 

: CONCEPT 
:DEFINITION 
: DELAY 

:DO 

ZEND 

s EXCEPTION 
TERE ORD 
raul 
TPOREACH 
>FROM 

> FUNCTION 
> GENERATE 
HIDE 

: IMPORT 
SINBERIT. 
eINITTIALLY 
: INSTANCE 
: INVARIANT 
> MACHINE 

>: MESSAGE 

: MODEL 

70D 

7OF 

: OPERATOR 


OTHERWISE 
PERIOD 
RENAME 

REP LY 

SEND 

STATE 
TEMPORAL 
TIME 

TO 
TRANSACTION 
TRANSITION 
TPE 

VALUE 
VIRTUAL 
WHEN 

WHERE 


INTEGER_LITERAL 
REAL LITERAL 
CHAR LITERAL 
STRING LITERAL 


NAME 


! operator precedences 
! $left means 2+3+4 is 


left 
$left 
$left 
left 
left 
left 
left 
left 
left 
*nonassoc 
left 
tleft 
tleft 
‘left 
left 
$left 
left 


$% 
'attribute declarations 


$% 
! productions of the grammar 


Stare 
spec 


Ge 


(2+3)+4. 


a . 
ce 


é 
? 


1D IF e ley 
COMMA; 


EXCEPTION, 
é 
SUCH; 

IEF; 
IMPLIES; 

OR; 

AND; 

NOT; 

Ser, oe 
IN, RANGE; 

U, APPEND; 
eae é 


ee? 
, 


’ 


Leer J 
acd: 


ie Laer 
UMINUS; 

EXE: 
ao. 
STAR; 


é 
, 


PLUS, MiNUS, 
MUL, 


’ 


é 


PUGS & oe Gale ee) ae , 
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IPOS 5 Ieicyy 


DIV, MOD; 


sOTHERWISE 
:PERIOD 

: RENAME 
:REPLY 

: SEND 
;sSTATE 

: TEMPORAL 

: TIME 

320 

: TRANSACTION 
: TRANSITION 
:TYPE 

: VALUE 

: VIRTUAL 


:{Int} 
s{inth "(int 


enésnm win 
e e 


: {Quote} ({Char}* {Quote} 


:{Letter} {Alpha}* 


NAME, SEMI; 


NLT, NGT, NLE, +cE, EOV, NEG we 


DOT, WHERE; 


spec 


module 


function 


machine 


concepts END 


type 


concepts END 


definition 


instance 


interface 


spec module 


hd 


' A production with nothing after the "|" means the empty string 
! is a legal replacement for the left hand side. 


function 


{id 
machine 
aes 

type 

Be) 
definition 
Aiea) 


instance ! of a generic module 


i) 


optionally virtual FUNCTION interface messages concepts END 
Je 


! Virtual modules are for inheritance only, never used directly. 


Optionally virtual MACHINE interface state messages transactions temporals 


optionally virtual TYPE interface model messages transactions temporals 


DEFINITION interface concepts END 
{ } 


INSTANCE formal _name ’=’ actual_name END 


{ } 
INSTANCE foreach actual name END 


12} 
! For making instances or partial instantiations of generic modules. 


! The foreach clause allows defining sets of instances. 


formal name inherits imports export 


ied 
! This part describes the static aspects of a module’s interface. 


! The dynamic aspects of the interface are described in the messages. 
' A module is generic iff it has parameters. 


ig 


inherits 


hide 


renames 


imports 


export 


messages 


=e 


' The parameters can be constrained by a WHERE clause. 

! A module can inherit the behavior of other modules. 

' A module can import concepts from other modules. 

! A module can export concepts for use by other modules. 


inherits INHERIT actual _ name hide renames 


Lg 


! Ancestors are generalizations or simplified views of a module. 
' A module inherits all of the behavior of its ancestors. 

! Hiding a message or concept means it will not be inherited. 

! Inherited components can be renamed to avoid naming conflicts. 


HIDE name_list 
{aa} 


! Useful for providing limited views of an actor. 
! Different user classes may see different views of a system. 
! Messages and concepts can be hidden. 


renames RENAME NAME AS NAME 
{on} 


! Renaming is useful for preventing name conflicts when inheriting 
! from multiple sources, and for adapting modules for new uses. 

! The parameters, model and state components, messages, exceptions, 
! and concepts of an actor can be renamed. 


imports IMPORT name_list FROM actual name 
(2 


EXPORT name_list 
{ } 


messages message 


{ } 
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message 
: MESSAGE formal _message operator response 


C2) 


se 


response 
> response_body 
fiw} 
| response cases 


ead 


me 


response cases 
: WHEN expression list response_body response_cases 
iat 
| OTHERWISE response_body 
{ } 


me 


response_ body 
: choose reply sends transition 


to) 


=e 


choose 
MmenOOsr a ( able onli st -restrietion.~)" 
{ } 
{sat 
reply 
: REPLY actual message where 
Hos} 
| GENERATE actual_message where ! used in generators 
ee 
| 
el 
sends 
sends send 
{- 
| 
eo 
send 
> optional foreach SEND actual message TO actual_name where 
mt 
transition 


: TRANSITION expression list ! for describing state changes 
a 


ie 


formal message 


optional exception optional_formal_ name formal_arguments 


{ } 


ze 


actual message 


optional exception optional_actual_name 


eet 


Se 


where 


WHERE expression_list 
ent 
| 
precedence than WHERE 
fol 


we 


optionally virtual 
: VIRTUAL 


to 


a 


optional exception 
EXCEPTION 
eel 


Unit 


operator 
: OPERATOR Operator lise 
to) 


optional foreach 
: foreach 


Pou 


%prec SEMI 


%prec SEMI 


formal_arguments 


must have a lower 


foreach 
FOREACH *(’ field Jist restriction *)* 
i 
; 
!' foreach is used to describe a set of messages or instances 
concepts 
concepts concept 
ale 
| 
{ } 
; 
concept 


CONCEPT formal _ name ':’ type spec where 
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=e 


model 


ee 


state ! 


=e 


invariant ! 


initially 


™=s 


transactions 


transaction 


=e 


action list 


action 


! constants 


ie 
CONCEPT formal name formal_arguments where VALUE formal arguments where 
! functions, defined with preconditions and postconditions 


bd) 


' data types have conceptual models for values 
MODEL formal_arguments invariant 


i} 


machines have conceptual models for states 
STATE formal_arguments invariant initially 


{ } 


invariants are true for all states or instances 
INVARIANT expression list 
{ } 


initial conditions are true only at the beginning 
INITIALLY expression list 
{ } 


transactions transaction 


i} 


TRANSACTION formal name ‘=’ action list where 
{ } 


! Transactions are atomic. 
! The where clause can specify timing constraints. 


action list *;" action tprec SEMI ! sequence 
oe, 

action 

{ } 

action action prec STAR ! unordered set of actions 
{5} 

IF alternatives FI ' choice 

at 

DO alternatives OD ! repeated choice 

ee} 

actual name ! a normal message or subtransaction 
oe, 

EXCEPTION actual name ' an exception message 


oe 
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alternatives 
: alternatives OR guard action list 
ii 
| guard action list 
{ } 


guard 
: WHEN expression ARROW 
fcc} 
| 
(3) 
temporals 
: temporals temporal 
{ } 
| 
{ } 
temporal 


TEMPORAL NAME where response 
i 


! Temporal events are trigged at absolute times, 
! in terms of the local clock of the actor. 

! The "where™ describes the triggering conditions 
f in terms of TIME, PERIOD, and DELAY. 


optional formal name 
: formal name 


fou 
| 


formal name 
: NAME formal parameters 


{ } 


=e 


formal parameters ! parameter values are determined at specification time 
7 4" fieldlrst: *)” where 
i) 
| 


formal _arguments ! arguments are evaluated at run-time 
2 (ei relam iste) 
{ } 
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Preid list 
7 fieldvlicue-, field 
ae 
| field 
{7} 


=e 


field 


ee 


name_list ’:’ type spec 

te 

| ’$’ NAME ’:’ type spec 
, 

| , ? ’ 


oe 


®e 


type spec 
: actual _name ! name of a data type 
i 


te! 


{ } 


name_list 
name_list NAME 
tee) 
| NAME 
fee} 


optional actual name 
> actual name 
fy 
| 
ad 


we 


actual _ name 
: NAME actual parameters 


et 


we 


actual parameters ! parameter values are determined at specification time 
weeierarg listi%)) 
Lo 


| prec SEMI ! must have a lower 
precedence than ’ {’ 
{ } 
actual arguments ! arguments are evaluated at run-time 
eee oro dista.)” 
{ } 
| %prec SEMI ! must have a lower 


precedence than ” (’ 


es 


we 
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arg list 


arg 


expression li 


expression 


ee 


arg list 


arg 


{ } 


expression 


i) 
pair 


boli 


st 


expression_ 


i 


expression 


Td; 


quantifier 


|) 


actual name actual arguments 


an 


’ arg 


list ’°,’ expression 


prec COMMA 


prec 


prec 


COMMA 


COMMA 


‘(’ field tist réstriction BINDMexpression .)” 


actual name '@’ actual _ name actual arguments 


ee 


NOT expression 


Pe 


expression 


Lo 


expression 


a) 


expression 


toa 


expression 


™ 


expression 


{ } 


expression 


{ } 


expression 


ca 


expression 


{ } 


expression 
{ } 
expression 
Coa) 


expression 


io 


expression 


{ } 


expression 


L|} 


expression 


oe 


expression 


OS 


AND expression 


OR expression 


IMPLIES expression 


IFF expression 
‘<’ expression 
‘>’ expression 
‘=’ expression 
LE expression 

GE expression 

NE expression 

NLT expression 
NGT expression 
NLE expression 


NGE expression 


EQV expression 
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prec 
tprec 
tprec 
tprec 
tprec 
prec 
prec 
prec 
prec 
tprec 
prec 
prec 
prec 
prec 
prec 


prec 


NOT 


AND 


OR 


IME LIES 


1 a 


LE 


LE 


LE 


LE 


LE 


LE 


LE 


LE 


LE 


LE 


LE 


— 


expression NEQV expression prec LE 


il 


’-' expression tprec UMINUS 
{ } 

expression ‘+’ expression prec PLUS 
ak 

expression ‘'-’ expression prec MINUS 
a 

expression '*’ expression prec MUL 

{ } 

expression '/’ expression &prec DIV 
ae 

expression MOD expression %prec MOD 

{ } 

expression EXP expression %prec EXP 
{et 

expression U expression tprec U 

out 

expression APPEND expression %prec APPEND 
a, 

expression IN expression tprec IN 
feos} 

‘*’ expression $prec STAR 


' *x is the value of x in the previous state 


Lt 


‘S$’ expression $prec DOT 

! $x represents a collection of items rather than just one 
' sl = {x, $s2} means sl = union({x}, s2) 

' sl = [x, $s2] means sl = append([x], s2) 

{. } 

expression RANGE expression %prec RANGE 
eT ieee Ol etx Aneta. «Dd ett a <= x <=. b 

! {a .. b]) is sorted in increasing order 

et 

expression ’.’ NAME tprec DOT 

ie 

expression ’[’ expression ’}’ $prec DOT 


ia 
mt Expression * )* 
{ } 
‘(’ expression NAME ‘)’ ! expression with units of measurement 
! standard time units: NANOSEC MICROSEC MILLISEC SECONDS 
MINUIES HOURS DAYS WEEKS 
1 


TEE, ' The current local time, used in temporal events 

ia} 

DELAY ' The time between the triggering event and the response 
1} 

PERIOD ' The time between successive events of this type 

ae 

literal 

oer 

literal ’@’ actual name ' literal with explicit type 
{ } 

ao ' An undefined value to be specified later 


et 


sae ' An unagefined and illegal value 


(eas 


IF expression THEN expression middle cases ELSE expression FI 


{ } 
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middle cases 


quantifier 


restriction 


literal 


=e 


=e 


middle cases ELSE IF expression THEN expression 


{ } 


ALL 
{ } 

SOME 

tS) 

NUMBER 

ian) 

SUM 

Li 

PRODUCT 

to 

SET 

i) 

MAXIMUM 

{i 

MINIMUM 

Ce 

UNION 

Li 
INTERSECTION 
i 


SUCH expression 


{ } 


INTEGER LITERAL 

{ } 

REAL LITERAL 

We, 

CHAR_LITERAL 

{ } 

STRING LITERAL 

{ } 

'#’ NAME 

{ } 

‘{’ expressions ’]’ 
i) 

‘{’ expressions '}’ 
{ } 

‘{’ expressions ';’ 
Oe) 

(* pair liste). 
{od 

TAY Wars aye 


{ } 


expression ‘}’ 


! relation literals are sets of tuples 


86 


! 


! enumeration type literal 
' sequence literal 
' set literal 
map literal 
' tuple literal 


1 One wor slrteral 


expressions 
: expression list 


Lo) 


as 


pair list 
Hemioy: oat DAUL) cmmarnnde yor. Yet 4 
{= 
{| NAME pair 
{ } 
{ pair 
a 
pair 


: NAME BIND expression 
ee 


=e 


operator list 
: operator list operator symbol 
ir 
| operator symbol 
Lo} 


we 


operator symbol 
J SOMe 


{ } 
| OR 
{ } 
| IMPLIES 
{ } 
| IFF 
{ } 
pees’ 
{ } 


| ay? 


a om = ms me ~”A~n~_ 
l * ~ oO ra 


—_— « —_— w tm ~~ F- ~~ dD 


— 
— 


| APPEND 
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APPENDIX B - CODE. 


This Appendix contains all of the code which was written or modified to implement 
the type checker. There are eight actual files contained in this Appendix. Each file has a 


unique purpose and the specifics of their use is detailed in the first file--makefile. 


1. MAKEFILE. 


spec: macros.m4 mylibcat.c spec.m4 
/n/suns2/usr/suns2/merge/BIN/kscript -DAGLEXDEBUG -DAGYACCDEBUG \ 
“t '%p 5000’ -t ’%a 5000’ -t ’%0 5000’ -t ’%e 5000’ -s -x -z -k -e\ 
-g -v -d /n/suns2/usr/suns2/merge/BIN \ 
-DUSERLIB=\"/n/suns2/usr/suns2/merge/kopas/thesis_imp/mylibcat.c\" spec.m4 


macros.m4: lib/head.m4 lib/attrib psg.m4 myconst.m4 mymac.m4 lib/tail.m4 
cat lib/head.m4 lib/attrib psg.m4 myconst.m4 mymac.m4 lib/tail.m4 >macros.m4 
chmod +r macros.m4 


mylibcat.c: /n/suns2/usr/suns2/merge/BIN/locallib.ec mylib.c 
cat /n/suns2/usr/suns2/merge/BIN/locallib.c mylib.c > mylibcat.c 
chmod +r mylibcat.c 


output: mylib.c lib/attrib_psg.m4 myconst.m4 mymac.m4 spec.m4 
print mylib.c myconst.m4 mymac.m4 spec.m4 
cat lib/attrib psg.m4 >! attrib psg.m4 
print attrib psg.m4 
rm attrib psg.m4 


2. ATTRIB_PSG.M4. 
/* 
. Macros for passing stuff around. 
* 
ee cascup 2, ‘$5’ .$2_s = $1.$2 s) 
define(passup 2, passup_1(51, $2); 


passup 1($1, $3)) 


define (passup 3, passup 1($1, $2); 
passup 1($1, $3); 
passup 1($1, $4)) 


define (passup 4, passup 1(51, $2); 
passup 1($1, $3); 
passup 1($1, $4); 
passup 1($1, $5)) 
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define (passup_5, passup 1($1, 
passup 1($1, $3); 
passup_ 1($1, $4); 
passup_1($1, $5); 
passup 1($1, $6)) 


define (passup 6, passup 1(S$1, 
passup 1($1, $3); 
passup_1($1, $4); 
passup 1($1, $5); 
passup 1($1, $6); 
passup_1($1, $7)) 


define (passup 7, passup 1($1, 
passup 1($1, $3); 
passup_1(S1, $4); 
passup 1($1, $5); 
passup 1($1, $6); 
passup_1($1, $7); 
passup 1($i, $8)) 


define (passup 8, passup 1(S51, 
passup 1(S17 S53); 
passup 1($1, $4); 
passup 1($1, $5); 
passup 1($1, 56); 
passup 1($1, $7); 
passup 1($1, $8); 
passup_1($1, $9)) 


define (passdn_l, 


define (passdn 2, passdn_1($1, 
passdn_1($1, $3)) 


define (passdn_ 3, passdn 1($1, 
passdn_1(51, $3); 
passdn_1($1, $4)) 


define (passdn 4, passdn 1($1, 
passdn 1($1, $3); 
passdn 1($1, $4); 
passdn_1($1, $5)) 


define (passdn_5, passdn_1($1, 
passdn_1($1, $3); 
passdn_ 1($1, $4); 
passdn_1($1, $5); 
passdn_1($1, $6)) 


define (passdn_ 6, passdn_ 1($1, 
passdn_1($1, $3); 
passdn_1($1, $4); 
passdn_1($1, $5); 
passdn 1($1, $6); 
passdn_1($1, $7)) 


define(passdn2 1, $1.$3_i = ‘$$’.$3_i; 


$2.$3_i = ‘$$’.$3_ i) 


oe Jue 


$2)7 


SZ) 


Siz ie 


$2); 


S203) 


o2)7 


S27) 


S25 


$1. S2iiemess” $200) 
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define (passdn2 2, passdn2_1($1, $2, $3); 
passdn2_ 1($1, $2, $4)) 


define (passdn2 3, passdn2_1($1, $2, $3); 
passdn2_1($1, $2, $4); 
passdn2_1(S1, $2, $5)) 


define(passdn2 4, passdn2_1(51, $2, $3); 
passdn2_1($1, $2, $4); 
passdn2_1($1, $2, $5); 
passdn2_ 1($1, $2, $6)) 


define (passdn2_ 5, Passdnzel(S1, $2, $3); 
passdn2_1($1, $2, $4); 
passdn2 1($1, $2, $5); 
Passdn2 1(51, $2, $6); 
passdn2_ 1($1, $2, $7)) 


define (passdn2 6, passdn2_1($1, $2, $3); 
passdn2_1($1, $2, $4); 
passdn2_1($1, $2, $5); 
passdn2_1($1, $2, $6); 
passdn2_1($1, $2, $7); 
passdn2_1($1, $2, $8)) 


define (passdn3 1, $1.$4 1 = ‘SS’ .$4 i; 
$2.84 i = ‘S$°.$4 i; 
$3.$4 i = *$$’.$4 i) 


define (passdn3 2, bassdns 151). 92,0827. 94) 3 
passdnsei(si, 32, 332; 32)) 


define(passdn3 3, Passan set (el, $2,553,954); 
pPassans (sly s2, $3, $5); 
passdn3_i($1, $2, $3, $6)) 


define (passdn3 4, passdn3 1($1, $2, 33, $4); 
Pessdnom(s ls oe, 95) 29) 
passdn3 1($1, $2, $3, $6); 
passdns i(S1, $2, $3, $7)) 


define (passdn3 5, passon2 1(-1, $2, $3, 34); 
Pesconosl(el, $2, 33, $9); 
Passame wis), 52, 53,/.26) 7 
Pascensslisi, S2, 535. 57): 
passan3_i($1, $2, $3, $8)) 


define (passdn4 1, passdn2 1($1, $2, $5); 
passdn2_1($3, $4, $5)) 
define (passdn4 2, passdn4 1($1, $2, $3, $4, $5); 
passdn4 1(S1, $2, $3, $4, $6€)) 
define(passdn5 1, passdn3 1($1, $2, $3, $6); 


passcn2 1(54, $5, $6)) 


/* 
* Passovr is used for passing attributes from one non-terminal to another. 
eeame order is (from,to,attribute,...) 
“id 

define(passovr 1, $2.53 i = $1.$3_ 8) 


91 


define (passovr_2, 


passovr_1($1, $2, 


Sa 


passovr 1($1,$2,$54)) 


define (passovr_3, 


passovr_ 1($1, $2, 


Sonn 


passovr_1($1, $2, $4); 
passovr_1($1, $2, $5)) 


define(passovr_ 4, 


passovr 1($1, 
passovr_1($1, $2, 
passovr_1($1, $2, 
passovr_1($1, $2, 


define (passovr_5, 


passovr_1(S$1, 
passovr_ 1(51, 
passovr 1($1, 
passovr_1($1, $2, 
passovr_1($1, $2, 


define (passovr_6, 


passovr 1($1, 
passovr 1(51, 
passovr 1($1, 
passovr 1($1, 
passovr_1($1, 


passovr 1($1, $2, 


Soe 
52, 24). 
$5)3 
$6)) 
ee) 
Say 
$2, 
$2, 


$4); 
$5); 
$6); 
$7)) 
2). 
$2, 
S2; 
SZ, 
SZ, 
a2, 


$4); 
$5); 
$6); 
oe 
$8)) 


* Pass information about in pre-order. 


Attribute comes last. 


/ 
define(passio0d 1, 


define(passiol 1, 
‘$$’ .$2 s 


define (passio2717 
$2.$3 i= 
‘$$ .$3_s 


define (passio3 1, 
$2.$4 i = 
$3.$4 i = 
‘$$".5$4_s 


define (passio0 2, 


Parent is first argument, 


names as appropriate... 


then children left to right. 
Macro appends i and __s to attribute 


*§$'.$1 s = ‘$$".$1 i) 


$1.$2 i = ‘$$’ .$2_i;3 
= $1.$2 s) 


91.93 i:= ‘$$’ .$3_i; 
$1.$3_s;3 
= $2.$3_s) 


$1.$4 i = 
$1.34 _s; 
$2.54 s; 
= $3.$4 s) 


5i6 a6 Aue 


passio0 1($1); 


passio0O 1($2)) 


define (passio0 3, 


passio0 1($1); 


passioO 1($2); 
passioO 1(53)) 


define (passio0_ 4, 


Passio071 (5 1)7 


passioO 1($2); 
passioO 1($3); 
passioO 1($4)) 


oo 


define (passio( 6, passio0 1($1); 
passioO 1($2); 
passio0 1($3); 
passioO 1($4); 
passio0 1($5); 
passio0 1($6)) 


define(passiol 2, passiol 1($1, $2); 
passiol 1($1, $3)) 


define (passiol 3, passiol 1($1, $2); 
passiol 1($1, $3); 
passiol 1($1, $4)) 


define(passiol 4, passiol 1($1, $2); 
passiol 1($1, $3); 
passiol 1($1, $4); 
passiol 1($1, $5)) 


define(passiol 5, passiol 1($1, $2); 
Bessi1cle 151,793) 
passiol 1($1, $4); 
passiol 1($1, $5); 
passiol 1($1, $6)) 


sertine(passioc2 2, passio2 1($1, $2, $3); 
passio2 1(91;, $2, $4)) 


aetine(passio2 3, Pass 162 (51,552; 33)? 
passio2 1($1, $2, $4); 
passio2 1($1, $2, $5)) 


define(passio2 4, passioz 1(51, $2, $3); 
passio2 1($1, $2, $4); 
Passitozeitsl, 92, $5); 
passio2 1($1, $2, $6)) 


define (passio2 5, passio2_1($1, $2, $3)? 
passioz 1($1, $2, $4); 
Passiozei(51, $2, 55) 7 
passio2 1($1, $2, $6); 
Passio2 1(S1, $2, $7) ) 


define(passio3 2, pPassiose (sl, s2, 93, 54), 
passios 1($1, $2, $3, $3)) 


define (passio3 3, passio3 1(51, $2, $3, $4); 
passio3 1($1, $2, $3, $5); 
passio3 1($1, $2, $3, $6)) 


define (passio3 4, passio3 1($1, $2, $3, $4); 
PassiOcm) (91,527) 275,550). 
passio3 1(51, $2, $3, $6); 
passic3 1(91, $2, 33, $7)) 


oo 


define (passio3_5, 


/* pass up strings, 
define (catstrup2 1, 
define(catstrup3_l, 


/* pass up maps, 


define (catmapup2_1, 
define (catmapup3 1, 
define (passovr2x_ 1, 
define (passovr3x_l, 


define (passovr4x 1, 


define (passovr2x 2, 


SZ, 

$5)? 
$6); 
$7); 
Se) 


passio3 1(S51, $3, 
$2, $3, 
$2, $3, 
$2, $3, 


$2, $3, 


passio3 1(51, 
passio3 1(51, 
passio3 1(S$1, 
passio3 1(51, 


concatenated together */ 
N35 930s 
‘$$’ .$4_s 


concatenated together */ 
‘$5’ .$3_s 
‘$$’ .$4_ s $1.$4 s +| 
passovr 1($1,52,54); 
passovr 1($1,53,54)) 
passovr2x_1(51,52,53,55); 
passovr 1($1,54,$5)) 
passovr2x_1(51,$2,53,56); 
passovr2x_1(51,54,$5,56)) 
passovr_2($1,$2,$4,$5); 
passovr 2($1,93,54,$55)) 


$4); 


$1.$3_s * 52.$3_s) 
$1.54 s * $2.54 s * $3.54 3s) 


$1.$3_s +| $2.$3_s) 
$2.$4_s +] $3.84 s) 


define (passovr3x_2, passovr3x_1($1, $2, $3, $4, $5); 
passovr3x_1($1, $2, $3, $4, $6)) 
define (passovr4x 2, passovr4x_1(51, $2, $3, $4, $5, $6); 
passovr4x 1($1, $2, $3, $4, $5, $7)) 
/* 
* weave -- a partial version of passio. 
: weave assumes the first nonterminal generates the attribute, 
bd and all non-terminals listed use the product of the previor 
il nonterminal, but the attribute is not returned to the parenz 
= nonterminal after it’s use by the last nonterminal. 
wy 


define (weave3 1, 


define (weave4 1, 


define (weave3 2, 


define (weave4 2, 


define(passio4 1, 


define (passio4 2, 


passovr($1,$2,$4); 
passovr ($2,$3,$4)) 


o2, 
$4, 


$3, 
$5)) 


weave3 1(S1, $3)? 


passovr ($3, 


$2, 
$2, 


weave3 1($1, 
weave3 1(S51, 


$3, 
$3, 


$4)? 
$5)) 


$2, 
$2, 


weave4 1(51, 
weave4 1(S1, 


$3, 
Sey 


$4, 
$4, 


$5)? 
$6)) 


ol soo ete o> sade 

$2.55_i = §1.$5_s; 

$3.55_i = $2.$5_ s; 

$4.55_i = §3.55_s; 

*$5’.$5_s = $4.55 s) 

passio4d 1(51, $2, $3, $4,.55)7 
passio4 1(51, $2, $3, $4, $6)) 


94 


define (passio5 1, $1.$6 i = ‘$$’.$6_i; 
S27 Ome SSS 
So omer $2.$6_s; 
$4.$6 i = $3.$6 s; 
$5.$6 i = $4.86 s; 
‘$$’ .$6 s = $5.$6_s) 
define(passioS 2, passioS 1($1, $2, $3, $4, $5, $6); 
passioS 1($1, $2, $3, $4, $5, $7)) 
define(passio6 1, $1.$7_i = ‘$$’ .$7_i; 
$2.$7_i = $1.$7_s; 
$3.$7 i = $2.57_s; 
She Tal SORE SG 
$5.$7 i = $4.$7 s; 
SG.97 01 = "S9.9? Ss; 
‘$$’.$7 s = $6.$7_s) 
define(passio6 2, passio6_1($1, $2, $3, $4, $5, $6, $7); 
passio6é 1($1, $2, $3, $4, $5, $6, $8)) 


3. MYMAC.M4. 


/* Macros used for making declarations shorter. 
i 

define(IP_STBL_INFO, Ipeeubieclassas. = Int—> int; 
ip _stbl_names_s int->string; 
ip_stbl params _s int->string; 
ip stbl result_s : int->string; 
Gomsebleclass i + int=>int; 
ip stbl names i : int->string; 
ieestbl params i : int->string; 
teestb)l result i : int->string) 


@deftine(STBL INFO, stbl i : string->string->string; 
sebleclass i : int->int; 
Seblenames i < int->string; 
stbl params i : int->string; 
Sebleresult i : int->string) 


demene (VISIBILITY TBLS, Visible oypes (i> st ring->string; 
feerole types Ss : string->string; 
Visrble names i + string->string: 
visible names_s : string->string) 


define (IP_MCMXREF TBLS, SpeMeMmere roses String >st ring; 
MeemMemMxrer i : string->string) 


Tihs 

* Macro’s used for various tasks including defining names, etc. 

x 

x 

* mk simple & mk_complex are very much alike. mk_complex has arguments ($5) 
fet nougn . 

tf 


Je 


define (mk_simple_decl_io, $1_s = 


define (mk_simple decl, $5 = 


define (mk_complex_decl, $1._s = 


define(add_elem, $4 


($2 == NULL_STRING) 


-> ($1_i ($3) == NULL_STRING) 
-> {($3 : [XREF_DELIMITER, 12s($4)}])} +{ $1_i 
‘#'{($3 3: [XREF_DELIMITER, i2s($4), 
PATTERN_DELIMITER, $1_i ($3)])} +f $1_i 
ie ae 


($2 == NULL_STRING) 
-> ($1 ($3) == NULL_STRING) 


-> {($3 : [XREF_DELIMITER, i2s($4)])} +1 $1 
‘#'{($3 : {XREF_DELIMITER, i2s($4), 
PATTERN DELIMITER, $1 ($3)])} +I $1 
Be iad $1) 


($2 == NULL_STRING) 
NULL_STRING) 


=5) (se 53) 


=> {($3 5 155, XREF DEDIPATER 12s (S4yjeeey so] i 
“#'{($3 2: [$1_1 ($3), PATTERN DELIMITER, $5, 
XREF_ DELIMITER, i2s($4)])} +1 $1_i 
MA Teed) 
= $1 +] {(S2 $3)} ) 


* Macro’s used for passing around the symbol table information. 

* This is the stuff that never changes, e.g. is not modified during progress 
* of type checking a module. 

Symbol Table Information Consists of 


stbl 


* 
nN & W Nh FH 


stbl names 
sebleresuli 
stbl class 
stbl params 


/* symbol table building macros */ 


define(stbl buildod, 
define(stbl buildl, 
define(stbl build2, 
define(stbl build3, 
define(stbl] build4, 
define(stbl builds, 


define(stbl build6, 


define(passdn_ stbll, 
define(passdn stbl2, 


define(passdn_stbl3, 


passio0 4(ip_stbl_ class,ip stbl_names,ip_stbl params, 
ipeseol resul:)) 
passiol 4($1,ip_stbl _ class,ip_stbl_names,ip_stbl params, 
ip_stbl result)) 
passio2 4($1,$2,ip _stbl class,ip_stbl names, 
ip_stbl_ params, ip_stbl_ result)) 
passio3 4($1,$2,$3,ip _stbl_class,ip stbl_names, 
ip_stbl params, ip_stbl result)) 
passio4 2(51,$2,$3,$4,ip_stbl class,ip_ stbl_ names); 
passio4 2($1,52,$3,$4,ip_stbl params, ip_stbl_ result)) 
passioS 2($1,$2,$3,$4,$5,ip _stbl class,ip stbl_ names); 
passioS 2($1,$2,$3,$4,55,ip_stbl params, ip_stbl_ result) ) 
passio6 2($1,$2,$3,$4,55,$6,ip_stbl_ class,ip stbi_names); 
passio6 2($1,$2,$3,$4,$5,$6,ip_stbl params, ip_stbl_result)) 


Passdn S($1], stbl, stb] result, stolvelacs stb li names, 
stbl params) ) 

passdn2 5($1, $2, stbl, stbl_result, 
stbl params) ) 

passdn3_5($1, $2, $3, stbl, stbl_result, stbl_class, 
stbl_names,stbl params) ) 


stbl_ class, stbl_ names, 
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stbl_ class, 


define (passdn stbl4, passdn3 5($1, $2, $3, stbl, stbl_result, 


stbl_names,stbl_ params) ; 


passdn 5($4, stbl, stbl_ result, stbl_class, 


stbl names,stbl params) } 


define (passdn_ stbl5, passdn3_5(S$l, $2, $3, stbl, stbl_result, stbl_ class, 


stbl names,stbl params); 


passdn2_5($4, $5, stbl, stbl_ result, stbl class, 


stb] names,stbl_ params) ) 


define (passdn_stbl6, passdn3_5($1, $2, $3, stbl, stbl_result, stbl_class, 


stbl_ names,stbl params); 


passdn3_5($4, $5, $6, stbl, stbl_ result, stbl_ class, 


stb] names,stbl_ params) ) 


4. MYCONST.M4. 


/* Symbolic Constants used in Program -- Are always capitalized. */ 


define (NULL STRING, ‘""’) 

Serine (UNDEFINED TYPE, ‘*"Type Name Undefined.*”’) 
define (SPEC LIBRARY MODULE type, ‘"type”’) 
define(GLOBAL TYPE NAMES, ‘"#global#"’) 
define(CURRENT MODULE TAG, ‘"#current_module#"’ ) 
define (FALSE, 0) 

define (FUNCTION CLASS, 1) 

define (MACHINE CLASS, 2) 

define (TYPE CLASS, 3) 

define (DEFINITION CLASS, 4) 

define (INSTANCE CLASS, 5) 

define (MESSAGE CLASS, 6) 

define (CONCEPT CLASS1, 7) 

define (CONCEPT CLASS2, 8) 

define (VARIABLE CLASS, 9) 

define (TRANSACTION CLASS, 10) 

Geftme (TEMPORAL CLASS, 11) 

Femme {PATTERN DELIMITER, ‘"*"’) 

Semone (XREF DELIMITER, ‘**-"’) 
Semime (ELEM DELIMITER, ‘*";"") 
Semaine (REF SYMBOL, ‘*"*"’) 

define (ACTUAL DELIM, ‘";"%) 

demume (PAIR DELIM, ‘";"’) 


/* 
* Errors & Warning Messages Generated by Kodiyak code. 
*/ 

Beeime UNRESOLVED TYPE, -1) 

Serine (UNDECLARED TYPE, 3) 
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5. HEAD.M4. 


divert (-1) 


/* 

¥ 

* Copyright 1986, Robert Herndon 

vi (C) 1986, Robert Herndon 

* Modified by Robert Kopas 1989. 

x Purpose - To allow Consistency and implement macros needed 
¥ for the type checker. 

¥ 


6. TAIL.M4. 


/* 
x Many of m4’s keywords are commonly used words. Remove 
* all builtin macro names to suppress any unexpected side-effects. 
i 4 
undefine (‘#’) 
unde fine (‘changequote’” ) 
unde fine (‘define’) 
undefine (‘divnum’ ) 
undefine (‘dnl’) 
undefine( ‘dumpdef’ ) 
undefine(‘errprint’) 
undefine (‘eval’) 
unde fine( ‘ifdef?’ ) 
undefine(‘ifelse’) 
unde fine ( ‘include’ ) 
undefine(‘incr’) 
unde fine (‘index’) 
undefine(‘len’) 
undefine(‘maketemp’ ) 
undefine(‘sinclude’ ) 
undefine(‘substr’) 
undefine (‘syscmd’ ) 
undefine(‘translit’) 
undefine(‘undivert’) 
divert (0) 
unde fine(‘divert’) 
unde fine ( ‘undefine’ ) 


7. MYLIB.C. 


/* Symbolic Constant Declarations -- It is extremely important that 
these concur with those defined in mymac.m4 

it 4 

#define MYCHARLENMAX 10000 

#define MAX_XREF_NUM_LEN 20 

#define PATTERN DELIMITER ie 

#define XREF DELIMITER ‘-! 

#define ELEM DELIMITER ee 

#define END_ELEMENT(s) (*s == ELEM DELIMITER) 

#define END _ACTUALS(s) (*s == ’\0") 

#define END _FORMALS(s) (*s == XREF_ DELIMITER) 

#define END PATTERN (s) ("Ss == PATIERN DEL rer) 
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#define UNDEFINED TYPE "Type Name Undefined." 
#define CURRENT MODULE TAG "“#current_module#" 
#define MESSAGE CLASS 6 


/* errors -- those that are enumerated in mymac.m4 must concur with these 


also. 
sea 
#define NAME REDEFINED ut 
#define CNAME REDEFINED 2 
#define UNDECLARED TYPE 3 


#define NONSPECIFIC REFERENCE 4 


/* 
* Warning Messages 

~/ 
#define UNRESOLVED TYPE -l 


dnt last _ xref = 0; 


/* 
* v_get_new_xref has an argument named unused just to 
* satisfy Kodiyak syntactic requirements. 
* Everytime the routine is called, it will obtain a new, unique xref. 
a / 
Pmeevget new xref( unused ) 
char *unused; 
{ 


meturn (++last xref); 


char mychars [MYCHARLENMAX] ; 
int mycharlen = 0; 


wxrefs dump (xreftostrmap) 
xobject xreftostrmap; 
{ 

int cur_ index; 

xstring lookup elem; 


for (cur_index = 1; cur_index <= last_xref; cur_index++) { 
lookup elem = ximapslkup(xreftostrmap, cur_index); 
Beantct("\ttd : °,cur index) ; 
woutput (lookup elem); 
permet ("\n”™)} 
fflush (stdout); 


wxrefi_dump (xreftointmap) 
xobject xreftointmap; 
{ 

int cur_index; 

int lookup elem; 


Bemeccur index = 1; cur index <= last xref; cur index++) { 
lookup_elem = ximapilkup(xreftointmap, cur_index); 
printf("\ttd : td\n", cur_index, lookup _elem); 

Ehiush (stdout) ; 
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} 


wsmapi_ dump( mapname) 
xobject mapname; 
{ 
struct xmflatten f; 
xobject p; 
int defval; 
int defined; 
int range_val; 


if (!XHEAP(mapname) && !XPAIR(mapname) ) { 

xerr ("smapi_dump -- Non Map Argument \n", 0, 0, 0); 
} 
defined = XFALSE; 


defval = 0; 
xminit (€f, mapname); 
for (p = xmnext(&f); p.op type; p = xmnext(éf) ) { 
if (!XPAIR(p)) 
xerr("smapi_dump -- Corrupt map. \n",0,0,0); 


if (p.op type[0).op type) { 
range val = *(p.op type[1l].ip_ type); 
Drintrt ("Vets -> Rd\n", xtstrilatten(p-op type |(Gj) ranges val), 
fflush (stdout); 
} 
else if (!defined) { 
defval = *(p.op type([1l].ip_ type); 
defined = XTRUE; 
} 
} /* end for loop */ 
Print (" \t DEFAULT => d\n", defval); 
fflush (stdout); 


wsmaps dump( mapname) 
xobject mapname; 
{ 
struct xmflatten f; 
xobject p; 
xobject defval; 
int defined; 
xheap range_ val; 


1f (!XHEAP(mapname) && !XPAIR(mapname) ) { 
xerr ("smapi_dump -- Non Map Argument \n", 0, 0, 0); 
} 
defined = XFALSE; 
defval.op type = (xheap) 0; 
xminit (&f, mapname) ; 
for (p = xmnext (sf); p.op type; p = xmnext(&sf) ) { 
if (!XPAIR(p)) 
xerr( Smaps sdaump —— Corrupt wmap.\n 70, 0,0), 
if (p.op_type[0].op type) { 
range_val = p.op type[1].op type; 
printf("\t %s -> ", xtstrflatten(p.op type[0J)); 
xheapprint (stdout, range val); 
Drintit- mn): 
ffilush (stdout) ; 
} 


else if (!defined) { 
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defval = p.op type[1l]; 
defined = XTRUE; 
} 

} /* end for loop */ 
printf("\tDEFAULT -> ne 
xheapprint (stdout, defval); 
meant? ("\n"™) ; 
fflush (stdout); 


/* 

* copy_pattern -- designed to copy a specific pattern to a destination 

o address. It returns the length of the pattern copied or 0. 

ta if the pattern is a null string (or equivalent), a ‘’\0’ is copied. 
as 


int copy pattern (d_addr, s_addr, max_len) 
GNar *“d addr, *s addr; 

int max_len; 

{ 


ene char cnt = 0; 


for (;((*s_addr != PATTERN_DELIMITER) && (*s_addr != ’\0’) && (max_len > 0)) 
pe SuacGdr++, dvaddr-+, max len=-, char ¢cnt++) 
*d addr = *s addr; 
if (max_len > 0) { 
*d_ addr = ’\0’; 
meewrn (Chapecmtet 11) 79 /* anclude "\0")*/ 
} 


return (max_len); 


char *verror_message(err num, line_no, xa, xb, xc, xd ) 
aac err num; 

Dhiceline no; 

moojece Xa, xb, xc, xd; 


{ 


switch (err num) { 
case NAME REDEFINED: 
return vfmt("*** ERROR *** Line %d : Name Already Defined -- &s 
(ey item %s).\n", 
lane nO, xa, Xb); 


break; 
case CNAME REDEFINED: 
return vfmt("*** ERROR *** Line td : Name Already Defined -- %s(%s) 
(by item %s)\n", 
Pine no, Xay— Xo, Xe); 
break; 
case UNDECLARED TYPE: 
return vfmt("*** ERROR *** Line %d : Type Name Undeclared -- %s\n", 
line_no, xa); 
break; 


case NONSPECIFIC REFERENCE: 

EetuUrm vVimt("*** ERROR *** Line $d : Do you mean s\n", line no, xa); 
case UNRESOLVED TYPE: 

return vimt ("** WARNING ** Line %d : Unresolved type used\n", line no); 

break; . 
default: 
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break; 
} 


return "2 


#define more sig patterns(s) (*s_ t= >? Gr) 
#define next_pattern(s) for (;*s 4! 2 2c) 
if (*s++ == PATTERN DELIMITER) \ 
break 
#define next_element (s) for (;((*s t= *\0") Gs (*s t= XREF_ DELIMITER) ) as 
if (*s++ == ELEM DELIMITER) \ 
break 
int num_copied = 0; 
#define cp2mychars(s) if ((num_copied = copy pattern (émychars[mycharlen], \ 


s, MYCHARLENMAX - mycharlen))}) \ 
mycharlen = mycharlen + num_copied; \ 
else \ 
xerr ("MYCHARLENMAX exceeded -- increase 


MYCHARLENMAX.", \ 


if 


0,0,0) 


Name declaration routines. 


These routines check for the existence of a signature. 
If the signature exists, they return an error message stating that 
the signature cannot be redefined. Otherwise they return "" 


xstring vcheck_simple_decl (name_map, name, line_no, xref2name_map) 
xobject name_map, name; 

inte wines nc; 

xobject xref2name_map; 


{ 


char xref number [MAX_XREF_NUM LEN); 
char *patterns; 
Gbare tmp args; 


patterns = xtstrflatten (xsmapslkup(name map, name)); 
while more sig patterns(patterns) { 
if (*patterns == XREF DELIMITER) { /* empty pattern -- no args */ 
for (tmp_args = patterns; *tmp_args++ != XREF DELIMITER; ) 


e 
f 


if (copy pattern(xref number, tmp_args, MAX XREF NUM LEN)) 
return (xstring) verror message (NAME REDEFINED, line_no, name, ximapslkup( 
xref2name_map, atoi(xref_number))); 
else 
xerr ("Exceeded MAX XREF NUM_LEN -- Increase value...”,0,0,0); 
} 
else 
next _pattern(patterns) ; 
} 


return (xsCringj. 2: 
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xstring vcheck complex_decl (name_map, name, f args, line_no, xref2name_map) 
xobject name_map, name, f_args; 

int line_no; 

xobject xref2name_map; 


{ 


char *patterns; 

char *new_sig; 

char xref number [MAX_XREF_NUM_LEN]; 
char *tmp_ name, *tmp_args; 

int retval; 


mycharlen = 0; 
new sig = mychars; 
cp2mychars(xtstrflatten(f_args)); 
patterns = xtstrflatten(xsmapslkup(name_map, name)); 
Baile more sig patterns (patterns) { 
if (match £ fp (new_sig, patterns)) { 
for (tmp_args = patterns; *tmp_args++ != XREF DELIMITER; ) 
if (copy pattern(xref number, tmp_args, MAX XREF NUM _LEN)) { 
tmp name = &mychars([mycharlen]; 
cp2mychars (xtstrflatten (name) ); 
/* remove xref value and delimiter from args. */ 
for (tmp_args = new_sig;((*tmp_args != XREF_ DELIMITER) 6&& 
(*tmpsargs {= \0")) ;) 
tmp_argst+; 
*tmpoargs =" \0"; 
return (xstring) verror_ message (CNAME REDEFINED, line_no, name, new sig, 
ximapslkup(xref2name_map, atoi(xref_number))); 
} 
else 
xerr ("Exceeded MAX XREF _NUM_LEN -- Increase value...”,0,0,0); 
} 
else { 
NeXt pactern (patterns) : 
} 
} /* end while */ 
Becurn (xstring) “"; 


/* type equal is strict equality. No allowances are made (or should be) 


for subtypes or equivalences. */ 


int type equal (argl, arg2) 
Guar ~argl, *arg2; 


{ 


/* position both args at beginning of type. */ 


while (*argl++ != ‘3:’) 
while (*arg2++ != '3;") 
for (; *argl == *arg2; argl++, arg2++) 
fot (arg), == LEM DELIMITER) || (*argl == XREF DELIMITER) ) 


return(1); 
Pe an exception condition. */ 


Ore (“arg] == “\0") && (*arg2 == XREF_ DELIMITER) ) 
return(1l); 
return (0); 
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int match f fp (temp_new, temp_old) 
char *temp_ new, *temp_ old; 


{ 
while ((*temp_new != ’\0’) && (*temp_old != XREF DELIMITER)) { 


if (type equal(temp_new, temp_old)) { 
if ((*temp_new == ’$’) && (*temp_old == ’$’)) { 
next_element (temp_new) ; 
next element (temp_old); 
} 
else if (*temp_new == '$’) { 
/* a recursive analysis must be done here. */ 
return (0); 5/*for mows. 
} 
else if (*temp old == ’$’) { 
/* another recursive analysis */ 
return (0); /*forenow *“/ 
} 
else { 
next_element (temp_new); 
next element (temp_old); 
} 
} 


/* the following two cases are for 0 arguments. */ 
else if (*temp_new == ’$’) { 
next element (temp_new); 
} 
else if (*temp_old == ’$’) { 
nextuelemenc (Cemp old): 
} 
else 
return (0); 
} /* end while */ 
if ((*temp_new == ’\0’) && (*temp_old == XREF_DELIMITER) ) 
/* both at end of formals */ 
resurn (1); 
return (0); 


/* routines used in resolving types and references. */ 
char *myalloc (req size) 
int req size; 
{ 
char “p; 
if ((p = (ehar *) alloc (req size) ) == NULL) 
xerr("NO more Dynamic Storage Available", 0,0,0); 
return (p); 


char *save string (s) 
char *s; 


{ 
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enar *p; 


Pp = myalloc(strlen(s) + 1); 
sErepy(p, S&S); 
return (p); 


char *loose_string(s) 
ear *s; 
{ 

free(s); 

return (NULL) ; 


/* at -- locate a character ina string */ 
char *at(s, seek_char) 
enar *“s; 


char seek char; 
{ 
for (;*s t= *\0"s s++) 
df (*s == seek char) 
return (s) ; 
return (NULL); 


/* substr -- return a substring of the original string */ 
char *substr (start pos, last pos) 
Gate start pos, *last_ pos; 
{ 
char *ret string; 
Ghar *tmp ptr; 


if (start_pos == NULL) 
return (NULL); 
else if (last_pos == NULL) 
Beturn (Save string(start pos)); 
else { 
Pecmotring = myalloc(last pos -— start pos + 2); 
Bore (tmp per — ret String; start _pos <= last pos ; last post++, tmp ptr++) 
PeEmMpeptl = “Start pos: 


enar, element subdstr(s) 
char *s; 
{ 


ehnar “last elem; 
if ((last_elem = at(s, ELEM DELIMITER)) != NULL) 


return(substr(s, --last_elem)); 
return(substr(s, last_elem)); 
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char *get_arg type (actuals, cur_arg) 
char *actuals; 
int cur_arg; 
{ 
int tmp; 


for (tmp = 1; ((tmp != cur_arg) && !END ACTUALS(actuals)); tmp++) 


next_element (actuals); 
if END_ACTUALS (actuals) 

return (NULL); 
return(element_substr(actuals) ); 


int is pair(s) 
char *s; 
{ 
for (; !END_ FORMALS(s) && !END_ACTUALS(s) 
if ((*%s == *)") GG (es + 1) eee si) 
reLurn Ly 
return (0); 


int names_match (elementl, element2) 
char *elementl, *element2; 
{ 
for (; *elementl == *element2 ;) 
if (*element!] == *:") 
return (Ll): 
Fetven oO); 


int mystremp (argl, arg2) 
char *argl, “arg; 


{ 


for (; ((*argl == *arg2) |{ (END_FORMALS(arg]) 


if (END _FORMALS (argl)) 
returni( 1); 
return (0); 


int pullout sxcer Vstr) 

char) *Stz? 

{ 
char *Start pos, *end pos; 
char tmp_char; 
int retval; 


Start_pos = at(str, XREF DELIMITER) ; 
end_pos = at(str, PATTERN DELIMITER); 


tmp_char = *end pos; 

"end spos =" \0) ; 

ret vete— VS2i (start pos):, 
*end pos = tmp_char; 


return(retval); 


&& 
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'END_ELEMENT (s) 


2 
’ 


st++) 


&& END ACTUALS (arg2)} 


int type_match (formal, actual) 
char *formal, *actual; 
{ 
Bors (; “formal++ !* *:’ 3) 
; /*move past name */ 
if (mystremp(formal, actual)) 
reeurn (1); 
else if (mystremp(formal, UNDEFINED TYPE) || 
mystremp(actual, UNDEFINED TYPE) ) 
mneturn(1) ; 
return (0); 


/* 

function match fa 
-- checks if formals match actuals. 
-- returns: true or false. 

int f 

int match_fa (formals, actuals) 

char *formals, *actuals; 


{ 
while (!END FORMALS(formals) && !END ACTUALS(actuals)) { 


if (*formals == ’$’) 
tie (isipair{actuals)) 
if (names _match(formals, actuals)) { 


next_element (formals) ; 
next _element (actuals); 
} 
else 
next element (formals) ; 
else if (type match (formals, actuals) ) 
next element (actuals) ; 


else 
next element (formals) ; 
else { 
if (is_pair(actuals)) { /* name must bind */ 


if (!names_match(formals, actuals) ) 
return (0); 
else { /* advance actuals past bind */ 
Fora? “actuals++ !=—" 3" 3) 
actualst+; 
} 
pee Pena rel S.padr 5% / 
if (types match(formals, actuals)) { 
next_element (formals) ; 
next _element (actuals) ; 
} 
else 
return (0); 
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} 
if (END_FORMALS (formals) && END ACTUALS (actuals) ) 


return(1l); 
return (0); 


int Analyze patterns(pattern_string, actual args) 
char *pattern_string; 
char *actual args; 


{ 
char *tmp_ptr, *cur_pattern; 


if ((cur_pattern = pattern_string) == NULL) 
return (0); 
while (more_sig patterns(cur_pattern)) { 
if (match_fa (cur_pattern, actual_args)) 
return (pultout xref (cur pattern), 
else 
next pattern(cur pattern); 


} 


return (0); 


xstring vseek_ symbol (name, actual args, visible_names, stbl, stbl_ classes, 
stbl_ names, line_num) 
xobject name, actual args; 
XObJect visible names, 
xob ject stb, stblvclasses,. sible names, 
Behe line_num; 
{ 
xSstring patterns; 
int xref value, cur_arg, tmp_xref val; 
char *arg type_name; 
char “flat patterns, *flat actuals; 
char *other overloadings = NULL; 


patterns = xsmapslikup(name, visible names); 

flat _actuals = save string(xtstrflatten(actual args)); 

xref value = Analyze patterns(flat_patterns, flat _actuals); 
cur_arg = 1; 


/* search all other modules for overloadings */ 


while ((arg_ type name = get_arg type(flat_actuals, cur_arg)) != NULL) { 
if (stremp(arg_type_name, xtstrflatten(xsmapslkup(visible names, 
CURRENT MODULE_TAG)))) { 


/* not current module */ 
patterns = xsmapslkup(xsmapxlkup(stbl, arg type _name), name); 
flat_patterns = loose _string(flat_patterns) ; 
flat_patterns = save string(xtstrflatten(patterns)); 
tmp_xref_val = Analyze patterns(flat patterns, flat_actuals); 
if (ximapilkup(stbl_ classes, tmp_xref_val) == MESSAGE CLASS) { 
if (xref value && tmp xref val) { 
/* multiple overloadings */ 
if (other overloadings == NULL) 
other overloadings = vfmt ("ts or %s", 
ximapslkup(stbl_ names, xref value), 
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ximapslkup(stbl_ names, tmp_xref_val} ); 
else 
other_overloadings = vfmt("%s, %s", 
ximapslkup(stbl_ names, tmp_xref_val), other_overloadings) ; 
) 
else if (!xref_value} 
xref value = tmp_xref_val; 


} 
cur_arg++; 
} /* end of while loop */ 


if (other _overloadings == NULL) 
return vi2s(xref value}; 
return verror_message (NONSPECIFIC REFERENCE, line num, other _overloadings); 


8. SPEC.M4. 


! version stamp $Header: spec.k,v 1.10 89/02/11 20:11:31 berzins Locked $§$ 
! Kopas- Revised Grammar iaw v 1.11 05 April 89 
! Kopas- Completed Declarations 20 April 89 


! In the grammar, comments go from a "!" to the end of the line. 

! Terminal symbols are entirely upper case or enclosed in single quotes (’). 

! Nonterminal symbols are entirely lower case. 

' Lexical character classes start with a captial letter and are enclosed in {}. 
! In a regular expression, x+ means one or more x’s. 


! In a regular expression, x* means zero or more x’s. 

! In a regular expression, [xyz] means x or y or 2z. 

!' In a regular expression, [*xyz] means any character except x or y or z. 
! In a regular expression, [a-z] means any character between a and z. 

! In a regular expression, . means any character except newline. 


'm4 inclusion files: mymac.m4 
include (macros.m4) 


! definitions of lexical classes 


define Digit : [0-9] 

tdefine int s( Digit} > 

tdefine Letter : [a-2zA-Z]) 

define Alpha sti betrer} | (Digit}i% ™) 

tdefine Blank Sve xt] 

define Quote Sa (r) 

define Backslash SoA 

tdefine Ghar 2({*"\\) | {Backslash) {Quote} | {Backs 


lash} {Backslash}) 
! definitions of white space and comments 


:{Blank}+ 


ee A oe 


! definitions of compound symbols and keywords 
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' I had to add the following terminal names to get line numbers... 


LBRACK 
DOTMARK 

SLASH 
STARMARK 
MINUSMARK 

P LUSMARK 
EQUALS 

GT 

1c 

QUESTION MARK 


tend of my additions 


AND 

OR 

NOT 
IMPLIES 
IEE 


LE 
GE 
NE 
NLT 
NGT 
NLE 
NGE 
EQV 
NEQV 


RANGE 
APPEND 
MOD 
EXP 


BIND 
ARROW 


LE 
THEN 
EDS 
IN 

U 


ALL 
SOME 
NUMBER 

SUM 
PRODUCT 
SET 
MAXIMUM 
MINIMUM 
UNION 
INTERSECTION 
SUCH 

ELSE IF 


AS 

CHOOSE 
CONCEPT 
DEFINITION 
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oe 


:{Backslash} |MOD 


eMe a 
e 


2f#Lyn 


atic: 

: THEN 
aes ASS 
sn 
2U 


:ALL 

: SOME 

:NUMBER 

>SUM 

sPRODUCT 

recjadh 

>: MAXIMUM 
>MINIMUM 

: UNION 

: INTERSECTION 
:SUCH{Blank}*THAT 
sELSE{Blank}*IF 


:AS 

: CHOOSE 

: CONCEPT 
SOELT INI TION 


DELAY 

DO 

END 
EXCEPTION 
EXPORT 

Fi 
FOREACH 
FROM 
FUNCTION 
GENERATE 
HIDE 
IMPORT 
INHERIT 
INITIALLY 
INSTANCE 
INVARIANT 
MACHINE 
MESSAGE 
MODEL 

OD 

OF 
OPERATOR 
OTHERWISE 
PERIOD 
RENAME 
REPLY 
SEND 
STATE 
TEMPORAL 
TIME 

die) 


TRANSACTION 
TRANSITION 


TYPE 
VALUE 
VIRTUAL 
WHEN 
WHERE 


INTEGER LITERAL 
REAL LITERAL 
CHAR LITERAL 
STRING LITERAL 


NAME 


! operator precedences 
! left means 2+3+4 is (2+3)+4. 


‘left 
tleft 
left 
$left 
left 
left 
tleft 
left 
left 
%$nonassoc 
tleft 
tleft 


‘ie per DO, ACE e1lLON, NAME; SEMI: 
pe ONMAS 

SUCH; 

Oa 

ivr LIES: 

OR; 

AND; 

NOT; 


LT, GT, EQUALS, LE, GE, NE, NLT, NGT, 


IN, RANGE; 
U, APPEND; 
PLUSMARK, MINUSMARK, PLUS, MINUS; 


it 


2DEEAY 

7DO 

SEND 
sEXCEPTION 
SEAPORT 
ame 

: FOREACH 
>FROM 
:>FUNCTION 
: GENERATE 
THLE 

7 Me OR 

: INHERIT 

s INITIALLY 
: INSTANCE 
: INVARIANT 
: MACHINE 

: MESSAGE 
:MODEL 

:OD 

SOF 

: OPERATOR 
: OTHERWISE 
SPERICD 


ra iL) 

: TRANSACTION 
: TRANSITION 
ties 

: VALUE 

: VIRTUAL 

: WHEN 

: WHERE 


Cine} 
CI Mc a le) 


:{Quote} {Char}* {Quote} 


:{Letter}{Alpha}* 


NLE, NGE, EQV, NEOV; 


§left STARMARK, SLASH, MUL, DIV, MOD; 


$left UMINUS; 

Sleft EXP; 

Sleft ‘S*, LBRAGCK eet, ° 1°. sPOTMARK pol WHERE > 
Sleft STAR; 

&% 


fattribute declarations 
!Terminals First 


BIND, ARROW, IF, THEN, ELSE, ALL, SOME, NUMBER, SUM, PRODUCT, SET, MAXIMUM, 
MINIMUM, UNION, INTERSECTION, SUCH, ELSE IF, AS, CHOOSE, CONCEPT, DEFINITION, 
DELAY, DO, END, EXCEPTION, EXPORT, FI, FOREACH, FROM, FUNCTION, GENERATE, HIDE, 
IMPORT, INHERIT, INITIALLY, INSTANCE, INVARIANT, MACHINE, MESSAGE, MODEL, OD, OF, 
OPERATOR, OTHERWISE, PERIOD, RENAME, REPLY, SEND, STATE, TEMPORAL, TIME, TO, 
TRANSACTION, TRANSITION, TYPE, VALUE, VIRTUAL, WHEN, WHERE { 

$line : int; 


QUESTION MARK, LT, GT, EQUALS, PLUSMARK, MINUSMARK, STARMARK, SLASH, 
DOTMARK, LBRACK { 

tline : int; 

&text : string; 


NOT, AND, OR, IMPLIES, IFF, LE, GE, NE, NLI, NGI, NLE, NGE, EOV, NEOV, 
MOD, EXP, U, APPEND, IN, RANGE { 

$text + string; 

Prine saints 


INTEGER_LITERAL, REAL LITERAL, CHAR_LITERAL, STRING_LITERAL { 
&text : string; 


Sline <9 int; 

} 

NAME { 
‘text 4: string: 
$line : int; 


'Now Nonterminals. 


spec { 
mod types Ss + string—>string->string- 
global type_s: string->string; 
type table i : string->string->string; 
ip mxref s =: string=>string, 
IP _STBL_INFO; 
ip _memxref i : string->string; 
ip_lelzd_memxref s : string->string->string; 


STBL_INFO; 


G€rror msgs Ss string; 


module { 


2 


mod types_s : string->string->string: 
global type_s: string->string; 
type table i : string=->string->string; 


toemxref s : string->string; 
foemxrerl 1 :; string=>string; 
HPaSTBL INFO; 

STBL_INFO; 


ipelelzd memxref s >; string->string->string; 
ip_memxref i : string->string; 


Senor msgs S ; string; 


Funccion { 
module name_s : string; 
mxref_value_s : int; 
MoGetypes S : String->string->string; 
mypeeceble i : string=->string->string?; 


ip mxref s : string->string; 
ieemeref i 3: string->string; 
HPeSTBL INFO; 

STBL_INFO; 

PESHEMAREF IBLS; 


Cferormmsgs Ss : string; 


machine { 
module name_s : string; 
memetovalue s : int; 


mod types s ; string->string->string; 
type table i : string->string->string; 
toeexcrer S > String->string; 

mommxrer i ; string->string; 
IP_STBL_INFO; 

STBL_INFO; 


IP_MCMXREF TBLS; 


Saaor msgs S : string; 


type { 
module name_s : string; 
mxref value_s : int; 
Meam@eypes S =: String->string->string; 
Piabal type Ss: string=>string; 
evocecable i : string=>string->string:; 


Moemxref s ; string->string; 
Mommxret i : string->string; 
ge sIBL INFO; 

STBL INFO; 

IP_ MCMXREF TBLS; 


error _msqgs_s : Scr ing, 


jy hs 


Gefinition { 
module name_s : string; 
mxref value_s : int; 
mod types s ; string->string->string; 
type table i : string->string-—>string; 


PpemMXSet es 2 Strings secing, 
ip _mxref 1 : String=>string; 
IP_STBL_INFO; 

STBL_INFO; 

IP_MCMXREF_TBLS; 


error msgs s : Bering; 


instance { 
module _name_s Strang, 
mxref value_s BANS 
type table 1: Sstring=>s Uring—-si_ring: 


ip mxref s : string->string; 
ipemxce fei SlrIng—-sr ning, 
IP_STBL_INFO; 

STBL_INFO; 

IP_MCMXREF_TBLS; 


error_msgs_s : string; 


dlerror 7s: . string; 


interface { 
module name s : string; 
mxref value _s : int; 
Bype (lable wis Sering-=string-=st ning, 
Q@nv i: int, 
VISIBILITY TBLS; 
ip_mxref s : string->string; 
ip mxrefoi gy: “string--staang-: 
IP STBL_ INFO; 
STBL_ INFO; 
error msgs s : string; 
d €5ror ss 3. string; 


inherits { 


Crror MSGS _S < “string: 


hide { 


error _msgs_s : string; 


renames { 


Grror MS65 5 2 )S-o1ne: 
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imports { 
Eype table i 


VisiBILITY TBLS 


IP_STBL_INFO; 
STBL_INFO; 


error _ msgs s 


export { 


error msgs_s 


messages { 
WaolBILITY TSBLS 


IP_MCMXREF TBLS 
IP_STBL_INFO; 
STBL_INFO; 


error _msgs_s 
message { 

Pasa eILITY TBLS 

IP_MCMXREF_TBLS 

IP_STBL_INFO; 

STBL_INFO; 

Error msgs s 


response { 
xref value i 


String->string->string; 


* 
e 


String: 


string; 


e 
td 


» 
e 


string? 


e 
td 


s 
e 


String; 


Ine: 


VISIBILITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


error_msgs_s 


response cases { 
xref value i 


String: 


ob euee 


VISIBILITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


error msgs_s 


Sto51nG; 


FS 


response body { 
xref value_i : int; 


VISIBILITY BLS, 


IP_STBL_INFO; 
STBL_INFO; 


error _msgs_s : string; 


choose { 
VISIBILITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


€rror mMSsGs_sS =: string; 


reply { 
xref value i : int; 


VISIBILITY IBLS; 


IP_STBL_INFO; 
STBL_INFO; 


error msgs Ss ; String: 


sencs { 
VISIBILITY TBLS, 


IP_STBL_ INFO; 
STBL_INFO; 


error _msgs_s : string; 


send { 
VISIBILITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


€rror mMsos 9s < string: 


transition < 
VISIBILITY TBLS; 


IP_STBL INFO; 
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STBL_INFO; 


error msgs_S : string; 


formal _message { 
mrec value s : int; 
message name_s : string; 
message fargs_s : string; 
PISIBILITY TBLS; 
IP _MCMXREF TBLS; 
IP_STBL INFO; 
STBL_INFO; 
Gmerror Ss : string; 


Seror msgs S : string; 


actual message { 
seeuatetext s >: string; 
VasIBILITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


©Crror msgs _s : string; 


where { 
VISIBILITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


Grror msgs s : string; 


optionally virtual { 
VISIBILITY TBLS; 


IP _STBL_ INFO; 
STBL_INFO; 


Srooremsgs S : string; 


optional exception { 
VisleILITY TBLS; 


IP_STBL_INFO; 
STBL_ INFO; 
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error msgs_s : string; 


operator { 
xref value i: int; 
message fargs_ i: string; 
Wee Be aoe 


VISIBILITY TBLS; 
IP_MCMXREF TBLS; 
IP_STBL_INFO; 
STBL_INFO; 


error_msgs_S : string; 


optional foreach { 
VISIBILITY TELS: 


IP_STBL_INFO; 
STBL_INFO; 


CrErOniisdses : stiing, 


foreach { 
VISIBIEITY TBLs; 


IP_STBL_INFO; 
STBL_INFO; 


error msgs _s ; string; 


concepts { 
module name i : string; 
local _types_s : string->string; 
VISIBILITY TBLS; 


IP_MCMXREF TBLS; 
IP STBL_ INFO; 
STBL_INFO; 


eller MSGS 5s + string: 


concept { 


local _types_s : string->string; 
module name i : string; 
MEGi ovalue ss + ints 
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FoslBILITY IBLS; 


IP_MCMXREF_TBLS; 
IP_STBL_INFO; 


STBL_INFO; 
Srror msgs _s : string; 
emerror s : string: 

} 

model { 


VISIBILITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


Grror msgs_s : string; 


state { 
VISIBILITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


SrECeeumsgs S : string; 


invariant { 
PrsisitaTyY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


@rror msgs_s : string; 


imgeraliy { 
VISIBILITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


eaueoremsgs S : string; 


transactions [{ 
pus tBILITY TIBLS; 


IP_STBL_INFO; 
STBL_INFO; 


Error msgs S : string; 


|, Jie, 


transaction { 
Gvereoruss.- String, 


VISIBILITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


error msgs_s : string; 


action list { 
VISIBILITY_TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


error msgs_sS : string; 


action { 
VISTEILITY ITBES; 


IP_STBL_INFO; 
STBL_INFO; 


error msgs_s : string; 


alternatives { 
VISIBIGITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


error msgs_s : string; 


guard { 
VISIBILITY _TBLS; 


IP_STBL_ INFO; 
STBL_INFO; 


G€rror MSGS Ss = String; 


temporals { 
VISIBILITY TBLS; 


IP_STBL_IXFO; 
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STBL_INFO; 


error msgs_s : string; 


temporal { 
xref value_s : int; 
@werror s ;: string; 


VISIBILITY TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


Grror msgs_s : string; 


optional formal name { 
name_text_s : string; 
name params _s : string; 
args i : string; 
env_i : int; 
xref value s : int; 
line s : int; 


VISIBILITY TBLS; 


IP STBL_ INFO; 
STBL_INFO; 


EesOr mSGS S : string; 


formal _ name { 
Bamestext Ss: string; 
NMame_params_s : string; 
evel): int; 
meer Value s : int; 
age 2 - string; 
Biness : int; 
Signature s : string; 


WISTBILITY TBLS; 


IP_STBL_ INFO; 
STBL_ INFO; 


@€rror msgs s : string; 
Gmerror Ss ; string; 


formal parameters { 
name_params s : string; 


VISIBILITY_TBLS; 


IP_STBL_INFO; 
STBL_INFO; 


error_msgs_S : string; 


formal arguments { 
name_fargs s : string; 
args text _s : string; 


IP_STBL_INFO; 
STBL_INFO; 


VISIBILITY TSLS; 


error _msgs_S : string; 


fieldalist., 
fieldpattern s : string; 
text s : string; 


IP_STBL_INFO; 
STBL_INFO; 


VISIBILITY IBLS; 


error msqs Ss : string; 


Ee cis 
Pi1elepatternas.: String, 
LexXt@ese. String, 
xref value s : int; 
Genrer s 3) String; 


IP_STBL_INFO; 
STBL_INFO; 


VISIBILITY_TBLS; 
error _msgs_S : string; 


declname list { 
name type text_i : string; 
name type value 1 : string; 
Lieldpatterngs > string, 
xrefivalpe Ss : ine. 
text _s : string; 
ETE ELOr esas st aang, 


IP_STBL_INFO; 
STBL_INFO; 


VISIBILITY TBLS; 


error msqs.S > String, 


iEype spec { 
type _name_text_s : string; 
type name_value_s : string; 


IP_STBL_INFO; 
STBL_INFO; 


VISIBILITY TBLS; 


error msgs_s : string; 
tmp_msg : string; 


name _list { 
error msgs s : string; 


} 


optional actual name { 
Puli name_s : string; 
actual params_s : string; 
actual name _text_s : string; 
mes : int; 


IP_STBL_INFO; 
STBL_INFO; 


PVistBILITY TBLS; 


SErer msgs S :; String; 


actual name { 
a@etual name text s : string; 
full name_s : string; 
actual params_s : string; 
tenes : int; 


IP_STBL_ INFO; 
STBL_INFO; 


MOStBILITY TBLS; 


Grror msgs s : string; 


actual parameters { 
actual params_s : string; 


IP _STBL_INFO; 
STBL_INFO; 


MeSsiIBILitTy TBLS; 


Seeonm msgs 5 : string; 
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actual arguments { 
fulleargs Ss : string; 


IP_STBL_INFO; 
STBL_INFO; 


VISIBILITY _TBLS; 


error msgs Ss : string; 


value_arguments { 
xref_value_i : int; 


IP_STBL_INFO; 
STBL_INFO; 
VISIBILITY TBLS; 


error _msgs_s : string; 


args saan 
arglist text_s : string; 


IP_STBL_INFO; 
STBL_INFO; 


VISTBILCITY TBs; 


@rrOr msgs S = ¢sStni1nG, 


arg { 
arg text s ; string; 


IP_STBL_INFO; 
STBL_ INFO; 


VISTEIiTY TBLS; 


error msgs s : string; 


expression list { 
KEen type = = string; 


IP_STBL_INFO; 
STBL_INFO; 


VISIBILITY _TBLS; 


CrrToOr MSGS 5. st ling, 


expression { 
meh cype S : String; 


IP_STBL_INFO; 
STBL_INFO; 


PISISILITY TSLS; 


@Eror msgs s : string; 


middle cases { 
IP_STBL_INFO; 
STBL_INFO; 
VISIBILITY _TBLS; 


error msgs_s : string; 


Reseriction { 
IP_STBL_ INFO; 
STBL_INFO; 
MarsiBiILiTy TBLSs; 


error MSgs S : string; 


literal { 
mien type Ss : string; 


IP_STBL INFO; 
STBL_INFO; 


VISIBILITY TBLS; 


error msgs S : string; 


expressions { 
mecmetype S :; string; 


IP_STBL_ INFO; 
STBL_INFO; 


WesIBILITY TSBLS; 


error msgs Ss : string; 


Pair lisc | 
xten_type_s : string; 


IP_STBL_INFO; 
STBL_INFO; 


VISIBILITY_TBLS; 


error msgs_s : string; 


pair { 
xten_type_s : string; 
type_s : string; 


IP_STBL_INFO; 
STBL_INFO; 


VISIBILITY TBLS; 


error msgs_s : string; 


operator list { 
xref value i : int; 
message fargs i : string; 
PIRemse.) tht, 


STBL_INFO; 
IP_MCMXREF_ TBLS; 


d error -s : string; 
error msgs_S : string; 


operator symbol { 
Operator Lext S < string, 
liness =: Int; 


%% 
! productions of the grammar 


Start 
: spec 
{ 
si.type table i = $1.mod types s +|{ 
{ (GLOBAL TYPE NAMES 


tt 


Sl.ip_stbl class i 
Sl.ip_stbl names i 
Sl.ip_stbl params i 


tt 


$1.global type_s) 


((27os inte: FALSE) 
((? : int : NULL STRING) 
((? : int : NULL STRING) 


So. -ip_sthleresult ii) = 9 {(272 ines UGE 
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$l.stbl_ names_i = $l.ip_stbl_names_s; 
Si. StbDl classes so peste Dl class s; 
$1.stbl paramseig=—21- 1p Stbl params s; 
Sivstbl cesvultwig—7-).ip stb] results; 


Sleip memxre fei ol, ip mxret .s; 
7 lestbl i =es leap lelzd memxref s; 


' test values 

fMoutput ("TYPES\n1. Global\n"™); 

&smaps dump($l.type_table_i (GLOBAL _TYPE_NAMES) ); 
$output ("2. From module testl\n"); 

%smaps dump($l.type table i ("test1")); 
$output ("3. From module test4\n"); 
tsmaps_dump($l.type table i ("test4")); 
$output ("4. From module test7\n"); 
tsmaps_dump($l.type table i ("test?")); 
$output ("\n\nMODULE XREF \nModule Testl\n"); 
%smaps dump(51.stbl i("test1")); 

$output ("Module test4\n"); 

tsmaps_ dump($1.stbl_ i("test4")); 

$output ("Module test7\n"); 
$smaps_dump($l.stbl_i("test7")); 


! dump xref info & error messages. 
AGucpueE (™\ ANA") > 
Ree = = = 


foutput (*- Error Messages & Cross Reference Info -\n"); 


.C Melita saa ae SS a SK SSS la 
$output ($l1.error_msgs_s); 

$output ("\n\nCross Reference to Names.\n"); 

%xrefs dump($i.stbl names i); 

$output ("\n\nCross Reference to Name Classes.\n"); 
SxEcei dump (>l.sctbl class 1); 

%output ("\n\nCross Reference to Name Parameters.\n"); 
Sxnets dump($1.stbl.params_i); 

foutput ("\n\nCross Reference to Name Results. \n"); 
$xrefs dump($l.stbl result i); 


spec 
spec module 
{ 
catmapup2 1($1,52,moc_types); 
Ccatmapup2 1($1,$2,global type); 


'module names. 

passovr 1($i, $2, ip _mxref); 
Passup 1(52, ip mxref); 
'symbol table 

stbl build? (31,$2); 

passdn stbl2(Sl1, $2); 


{ pass down needed type translations. 
passdn2_ 1(S1, $2, type_table); 


passdn2 1(S1, $2, ip_memxref); 
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module 


catmapup2_1($l1, $2, ip_lclzd_mcmxref); 


$5.error_msgs s = [$l.error (mSGouegm-2-crror msgs Ss]; 


$$.mod_types_s = {(? : string : {(? : string : UNDEFINED TYPE) }) }- 
$$.global type _s = {(? : string : UNDEFINED TYPE) }; 


! module names & features. 
$$.ip_mxref_s = {(? : string : NULL_STRING) }; 


$$.ip_lclzd_memxref_s = {(? : string : {(? : string : NULL_STRING) }) }; 


!'symbol table 
stbl_ build0(); 


$$.error_msgs_s = ""; 


} 


*e 


! A production with nothing after the "|" means the empty string 
' is a legal replacement for the left hand side. 


: funececon 


{ 
passup_ 1($1, mod_types); 
$$.global type_s = {(? : string : UNDEFINED TYPE) }; 


passdn i (51, type table) 


'symbol table 

passiol 1($1, ip_mxref); 
Sto lpuildi (51); 

passdn stbl1($1); 


passdn_1($1, ip _memxref); 
$$.ip_lelzd_mcemxref_s = {($l1l.module_name_s : $1.ip mcmxref_ s) }; 


passup_1($1, error msgs); 


} 


i machine 
{ 
passup_1(51, mod_types); 
$$.global_type_s = {(? : string : UNDEFINED TYPE) }; 
passdn_1($1, type table); 


!'symbol table 

passiol 1($1, ip mxref); 
Sebi build] (si); 

passdn stbl1($1); 


passdn 1($1, ip_memxref); 
$$.ip_lclzd_mcmxref_s = {($1.module_name_s : $1l.ip memxref_s)}; 


passup_1($1, error msgs); 
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| type 
{ 
passup 2($1, mod_types, global type); 
passdn_1($1, type table); 


!'symbol table 

passiol 1($1, ip_mxref); 
stb) build! ($1); 
passdn_stbl1(51); 


passdn_1($1l, ip_mcemxref); 
$$.ip_lelzd_memxref_s = {($l.module_name_s : $1.ip_memxref_s) }; 


passup_1(S1, error_msgs); 
} 
| definition 


{ 
passup 1($1, mod types); 
$$.global type s = {(? : string : UNDEFINED TYPE) }; 


passdn_1(5l, type table); 


'symbol table 

passiol 1($1l, ip_mxref); 
Sebi ebuiidi(s)): 

passdn stb5ll(31); 


passdn_1($1, ip_memxref); 
$S.ip_leclzd_mcemxref_s = {($l.module_name_s : $1.ip_memxref_s)}; 


passup 1($1, error_msgs); 
} 


| instance ' of a generic module 


{ 
we-mod types Ss = {(?7 : string : {(? SCriIng a, (UNDEF ENED TYPE) })a): 


See lO0bd) type So—) {(2 2 string: UNDEFINED TYPE)  }7 
passdn_ 1($1, type table); 


'symbol table 

passiol 1(51, ip mxref); 
Sebi pulldl(s1); 
Passen sebi ($1); 


Passcanes! (51, ip memxret); 
Seip lcizd memxref s = {({5l1.medule name s =: Sl.ip mcecmxref s) }; 


Passuplitsl, 6rror msgs); 


=e 


function 
optionaily virtual FUNCTION interface messages concepts END 


{ 
passup 2($3,module_name, mxref_value); 
passovr 1($3, $5, module name); 
$3.env_i = FUNCTION CLASS; 


Oe, 


} 


! 


machine 


$$.mod types _s = {($3.module jnamemem-5- 0) local types s)}; 


passdn_1($3, type table); 
passio2 1($4,$5,ip_memxref); 


'symbol table 
passiol 1($3, ip_mxref); 


stbl_ build3 ($3, $4, $5); 
passdn_stbl13($3, $4, $5); 


'visibility information 
passovr2x_2($3, $4, $5, visible types, visible names) ; 


$$.error msgs_s = [($3.error_msgs_s, $4.error_msgs_s, $5.error _msgs_ 8]; 


Virtual modules are for inheritance only, never used directly. 


optionally virtual MACHINE interface state messages transactions temporals 


concepts END 


{ 


type 


passup 2($3,module_name, mxref_value); 

passovr_ 1($3, $8, module_name) ; 

$3.env_i = MACHINE CLASS; 

$$.mod_types_s = {($3.module_name_s : $8.local_types_s)}; 


passdn_1($3, type table); 
passio2 1($5, $8,ip_mcmxref); 


'symbol table 

passiol 1($3, ip_mxref); 
stb] _ build6é($3, $4, $5, $6, $7, $8); 
passdn_ stbl6($3, $4, $5, $6, $7, $8); 


‘visibility information: 

passovr 2($3,5$4,visible types, visible names); 
passovr2x_2($4,55,56,visible types, visible names) ; 
passovr2x 2($4,$7,$8, visible types, visible names) ; 


S$$.error msgs_s = (S$3.error_msgs_s, $5.error_msgs_s, $8.error_msgs_s}; 


optionally virtual TYPE interface model messages transactions temporals concepts 


END 


passup_2($3,module name, mxref_value); 

passovr_1($3, $8, module name); 

§3-€nv_i = TYPE CLASS; 

$$.mod_types_s = {($3.module_name_s : $8.local types_s )} ; 

$$.global_type_s = {($3.module_name_s : $3.module_name_s), 
(2 = string >; UNDEF INEDEI YEE 


passdn_1(S3, type table); 
passio2 1($5, $8, ip mcmxref); 


'symbol table 
passiol 1($3, ip mxref); 
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stb] build6é($3, $4, $5, $6, $7, $8); 
passdn_stbl6(53, $4, So, SG, ol; $8); 


'visibility information. 

passovr 2($3,$4,visible types, visible names); 
passovr2x_2($4,$5,$6,visible_ types, visible names); 
passovr2x_2($4,$7,$8, visible types, visible names); 


$$.error_msgs_s = [$3.error_msgs_s, $5.error_msgs_s, $8.error_msgs_ s); 


definition 
DEFINITION interface concepts END 
{ 
passup_2($2,module_name, mxref_value); 
passovr 1($2, $3, module name); 
$2.env_i = DEFINITION_CLASS; 
$$.mod_types_s = {($2.module_name_s : $3.local types_s)}; 


passdn_1($2, type_table); 
passiol 1($3, ip_mcemxref); 


'symbol table 

passiol 1($2, ip_mxref); 
Stbpl bude (32, 53); 
passdn_stb1l2($2, $3); 


visibility information. 
passovr 2($2, $3, visible types, visible names); 


S--error msgs Ss — [92.error msgs s, 53-error msgsus); 


instance 
INSTANCE formal _ name EQUALS actual name END 
{ 


$$.module name_s = $2.name_text_s; 
$2.env_i = INSTANCE CLASS; 
$$.mxref_value_s = $2.xref_value_s; 


passioO l(ip memxref); 


'symbol table 
$$.d error s = check simple decl($$.ip mxref i, $$.module name_s, $2.line s, 
$$.stbl_ names _ i); 
mk_ simple decl_ io($$.ip_mxref, $$.d_error_s, $5.module name_s, 
$$.mxref value_s); 
stbl build2($2, $4); 
passdn_stbl2($2, $4); 


iVis@oulity information. 
S2.visible types i = $$.type table _i (GLOBAL_TYPE NAMES); 
$2.visible names _ i = $$.stbl_i($$.module_name_s); 


passovr 2(S2, $4, visible types, visible names); 


$$.error_msgs_s = $5.d_ error s; 
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interface 


=e 


INSTANCE foreach actual name END 


{ 


: 
: 


! Check this entire section of code for interfaces... 
$$.module_name_s = $3.actual_ name_text_s; fcheck this w/ Prof. B. 
$$.mxref value_s = get_new_xref($3.actual_name_text_s); 
$$.d_error_s = check_simple_decl($$.ip_mxref_i, $$.module_name_s, $3.line_s, 
$$.stbl_names_ i); 
mk_simple_decl_io($$.ip_mxref, $$.d_error_s, $$.module_name_s, 
$$.mxref_value_s); 


passioO i(ip_ mcmxref); 


'symbol table 
stbl_build2 ($2,$3); 
passdn_stb12($2,$3); 


'visibility information 

$2.visible types i = $$.type_table_i (GLOBAL_TYPE_NAMES) ; 
$2.visible_names i = $$.stbl_i ($$.module_name_s); 
passovr 2($2, $3, visible names, visible types); 


$$.error_msgs_s = $$.d_error_s; 


For making instances or partial instantiations of generic modules. 
The foreach clause allows defining sets of instances. 


formal name inherits imports export 


{ 


: 


i 


$$.module_ name_s = oil.name_text_s; 
9$.mxref value_s = $i.xref value_s; 
Sl.args 1 = ™"; 


passdn_1($1, env); 
$$.d_error_s = check_simple decl($$.ip mxref_i, $$.module_name_s, $1.line s, 
$$.stbl_ names i); 
mk simple decl_io($$.ip mxref, $$.d_error_s, $$.module_name_s, 
$$.mxref value_s); 


'symbol table 
SED UeeulT GZ (si, so) 
passdn stbl2($i, $3); 


‘visibility information 
Sl.visible types i = $$.type table _i (GLOBAL_TYPE_NAMES); 
Sl.visible names i = $$.stbl_i ($$.module_name_s) +] 

{ (CURRENT MODULE TAG : $$.module name_s)}; 
$3.visible types i = $l.visible types _s +| 

SS.type table i ($$.module name s); 
passovr 1(S1, $3, visible names); 
passup_2($3, visible _ types, visible names); 


$$.error_ msgs _s = [$$.d_error_s, $l.error msgs _s]); 


This part describes the static aspects of a module’s interface. 
The dynamic aspects of the interface are described in the messages. 
A module is generic iff it has parameters. 


inherits 


hide 


renames 


imports 


export 


ee 


=e 


‘we 


! The parameters can be constrained by a WHERE clause. 

' A module can inherit the behavior of other modules. 

' A module can import concepts from other modules. 

! A module can export concepts for use by other modules. 


inherits INHERIT actual _ name hide renames 


{ } 


!' Ancestors are generalizations or simplified views of a module. 
! A module inherits all of the behavior of its ancestors. 

! Hiding a message or concept means it will not be inherited. 

! Inherited components can be renamed to avoid naming conflicts. 


HIDE name_list 
he 


!' Useful for providing limited views of an actor. 
! Different user classes may see different views of a system. 
! Messages and concepts can be hidden. 


renames RENAME NAME AS NAME 
{ } 


! Renaming is useful for preventing name conflicts when inheriting 
! from multiple sources, and for adapting modules for new uses. 

' The parameters, model and state components, messages, exceptions, 
! and concepts of an actor can be renamed. 


imports IMPORT name_list FROM actual _ name 


{ 


‘Visibiliey anformation:. 
passioO 2(visible types, visible names); 


'for now -- until importation implemented. 


stbl buildl($1); 
Bassam seb ll (S21); 


‘visibility information. 
passioO 2(visible types, visible names); 


!'symbol table 
secleburidd(); 


EXPORT name 11st 
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messages 
: messages message 
{ 
passio2 1($1, $2, ip_mcemxref); 


!'symbol table 
stbl_build2($l, $2); 
passdn_stb12($1, $2); 


{visibility information 
passdn2_2($1,$2, visible types, visible_names); 


'error messages 
$$.error_msgs_s = [($l.error_msgs_s, $2.error_msgs_s]); 


passioO 1(ip_mcmxref); 


'symbol table 
stbl_build0O(); 


‘error messages 
$$.error_ msgs _s = ""; 


message 
: MESSAGE formal message operator response 
{ 


passio2 1($2, $3, ip_memxref); 


passovr 2(52, 33, xnetivalue,) message targs), 
passovr_1($2, $4, xref_value); 


'symbol table 
St bigbuiides (S270 53, S4)7 
Dasscmes bls 2,ms os e214). 


'visibility information 
passdn_ 2(52, visible types, visible names); 
passovr 2($2, $4, visible types, visible names); 


'error messages 
$$.error_msgs_s = [$2.error_msgs_s, $3.error_msgs_s, $4.error_msgs_s]; 


response 
response body 
{ 


passdn_1($1, xref value); 


'symbol table 
st bivbur lal su 
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passdn_stbli($1); 


‘visibility information 
passdn 2(51, visible types, visible names); 


ferror messages 
passup 1($1, error_msgs); 
} 


| response_cases 


{ 


passdn_1($1, xref_value); 


!symbol table 
stbl buildl ($1); 


ivisibidity information 
passdn 2($1, visible types, visible names); 


lerror messages 
passup 1($1, error_msgs); 


response cases 
WHEN expression list response body response cases 
{ 
passdn2_1($3,54, xref_value); 


!'symbol table 
stbl_ build3 ($2, $3, $4); 
passam stbis($2, $3, 34); 


visibility information 
passdn3 _2(52, $3, $4, visible types, visible names); 


rerror messages 
29-enrOor msgs S — [52.ermor msgs _s, $3.error msgsus, $4.e€rnor msgs 5]; 
} 
| OTHERWISE response_ body 
{ 


passdn 1(S2, xref value); 


'symbol table 
Stub bul lal($2)4 
passdn_ stbl1($2); 


‘Visibility -informaticn 
passdn 2(52, visible types, visible names); 


lerror messages 
passup 1($2, error_msgs); 


response body 
choose reply sends transition 


{ 


passdn _1($2, xref value); 


4 
} 


symbol table 
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me 


choose 


stb] build4($1, $2, $3, $4); 
passdn_stbl14($1, $2, $3, $4); 


Ivisibility information 


passdn_2($1, visible types, visible names); 
passovr3x_2($1, $2, $3, $4, visible types, visible names); 


‘error messages 


$$.error msgs_s = [$l.error_msgs_s, $2.error_msgs_s, $3.error_msgs_s, 


$4.error_msgs_ s]}; 


; CHOOSES’ fielabiistr restriction.) 


{ 


reply 


'symbol table 
stbl_ build2($3, $4); 
passdn_ stb12($3, $4); 


Ivisibility information 
passiol 2($3, visible types, visible names); 
passovr_2($3, $4, visible types, visible names); 


‘error messages 
$$.error_msgs_s = ($3.error_msgs_s, $4.error_msgs_s]; 


!'symbol table 
Sstbiybuiido (i; 


ivisibi lity “informacion 
passio0 2(visible types, visible names) ; 


‘error messages 
$$.error msgs_s = ""; 


: REPLY actual _ message where 


{ 


} 


'symbol table 
passio2 3($2, $3, ip_stbli_class, ip_stbli_names, ip _stbl_params); 
$2Z.ip_stbl result i = $$.ip_stbi resuit i +| 
{($$.xref value _i 

$2.actual text_s)}; 
passovr 1($2, $3, ip_stbl_ result); 
passup 1($3, ip_stbl_ result); 
passdn_stbi12($2, $3); 


Ivisibility information 
passdn2_2($2, $3, visible_types, visible names); 


lerror messages 
$$.error_msgs_s = [$2.error_msgs_s, $3.error_msgs_s]; 


| GENERATE actual message where ! used in generators 


{ 


'symbol table 


136 


passio2 3($2, $3, ip_stbl_class, ip_stbl_names, ip_stbl_params); 
S2-1pescoleresnite. =.95.ip stb] result _i +] 

{($3.xref value i = $22actual text sj}; 
passovr 1($2, $3, ip_stbl_result); 
pessup 1 (53,7 ip stbl result); 
passdn_stbl2($2, $3); 


lvisibiliaty information 
passdn2_ 2($2, $3, visible types, visible names); 


‘error messages 
$$.error_msgs_s = [$2.error_msgs_s, $3.error_msgs_s); 


Stbl bulddo (); 


lerror messages 
$$.error_msgs_s es 


sends 
sends send 
{ 
stbl_ build2($1, $2); 
passdn stbl2($1, $2); 
Ivisibility information 
passdn2_ 2($1, $2, visible types, visible names); 
‘error messages 
$$.error msgs_s = [Si.error_msgs_s, $2.error msgs_s}; 
} 
| 
{ 
stbl build0d(); 
‘error messages 
$$.error msgs_s = ""; 
} 
send 


optional foreach SEND actual message TO actual_name where 
{ 

stbl_build4($1, $3, $5, $6); 

passdn_ stbl14($1, $3, $5, $6); 


Visibility antormation 
passdn4 2($1, $3, $5, $6, visible types, visible names); 


‘error messages 
Ss-.€rror msgs S = (|>93.erreor msgs s, SoSserror msgs s, $6.error.msgs s); 


transition 
TRANSITION expression list ' for describing state changes 


{ 
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stbl buildl ($2); 
passdn_ stbl1(S$2); 


‘visibility information 
passdn 2($2, visible types, visible names); 


‘error messages 
passup_1($2, error_msgs); 


stbl_ buildO(); 


‘error messages 
SS .error msqs us = ""; 


formal message 
optional_exception optional formal name formal_arguments 


{ 


$$.message name_s = $2.name_text_s; 
$$.message_fargs_s = $3.name_fargs_ s; 
$2.args_i = $3.args_text_s; 

$2.env_i = MESSAGE CLASS; 

passup 1($2, xref_value}; 


mk_complex_decl($$.ip_mcemxref, $5.d_error_s, $2.name_text_s, 
$2.xref_value_s, $3.name_fargs_s); 


'symbol table 
stbl_ build2($2, $3); 
passdn stbl2(527 053); 


'visibility information 
passio2 2($2, $3, visible types, visible names); 


‘error messages 

95.d_ error s = check complex decl(3$ ip memxretu1,. 7 onamemce seus: 
23.name_fargs s, $2.line s, 95.stbl names i); 

Ss .eL LOL MSGS ss =) |s2-C€rror mMSdSus,0 5s .eh ron mS ssi), 


actual message 
optional _exception optional actual name formal_arguments 


{ 


S$$.actual text_s = ($2.full_name_s == "") 
-> $3.name_fargs_s 
# ($3.name_fargs_s == "") 


-> $2.full_name_s 
to oe eu lle name es jt 
$3.name_fargs_s,")"]; 


Sth] bualdZie7pessie 
passdn stbhi2(S2)53)7 


ivisibility information 
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passdn2 2(52, $3, visible types, visible names); 


‘error messages 
$5.@rror msgs _s = [$2.error_msgs_S, $3.error msgs _s]; 


where 
: WHERE expression list 


{ 
stbl_ build ($2); 
passdn_stbl1($2); 


'visibility information 
passdn 2($2, visible types, visible_names); 


terror messages 
passup 1($2, error _msgs); 


prec SEMI ! must have a lower precedence than WHERE 
Stbl build); 


'error messages 
$$.error_msgs_s = ""; 


optionally virtual 
>: VIRTUAL 
{ } 


i} 


Spe1onal exception 
EXCEPTION 
{>} 
| tprec SEMI 


operator 
: OPERATOR operator list 
{ 
passdn 2($2, xref_value, message fargs); 
posslol i(s2, ip memxref) ; 


!'symbol table 
St bl burldo(); 
Passen stbill(s2); 


'error messages 
passup 1($2, error msgs); 


passioO 1l(ip memxref); 


!'symbol table 
Seow burl do(); 
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$$.error msgs_s = ""; 


optional foreach 
foreach 


=e 


foreach 


=e 


concepts 


{ 


Sebi bud lds) 
passdn_stbl1($1); 


lyisibility information 
passdn_2(S$1, visible types, visible names); 


'error messages 
passup 1($1, error_msgs); 


stbl_ build0O(); 


'error messages 
So.GLrCr MSOses = "> 


FOREACH ( (fieldwlisteneserict i ome. 
{ 


: 


stbl build2($3, $4); 
passdn_stbl2($3, $4); 


visibility information 
passio2 2($3, $4, visible types, visible names); 


'error messages 
$$.error_msgs_s = [$3.error_msgs_s, $4.error_msgs_s]; 


foreach is used to describe a set of messages or instances 


concepts concept 


{ 


passdn2_ 1($1, $2, module name); 
catmapup2_1(51,$2,local types); 
passio2 1($1,52, ip_mcemxref) ; 


'symbol table 


stbl buadild2 ($i, $25 
passcn stbl2 (51, $2); 


‘visibility information 
passdn2 2(S1, $2, visible types, visible names); 


'error messages 
$$.error msgs_s = ($l.error_msgs_s, $2.error_msgs_s]; 
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SS. leocaWetypesuSen (- = String : UNDEFINED TYPE) ); 
passio0 1(ip_mcmxref); 


'symbol table 
stb] build0(); 


'errror messages 
$$.error msgs_s = "7; 


concept 
: CONCEPT formal name ’:’ type_spec where 
} constants 


{ 


$$.local_types_s = ($4.type_name_text_s == SPEC LIBRARY MODULE type) 
-> { ($2.name_text_s : [$2.name_text_s, *@", $$.module_name_i]) } 
* 
feEGoeomoering > UNDEFINED ITYPs..)) } > 


passup 1(S2, xref value); 
$$.d_error_s = check simple decl($$.ip_memxref_i, $2.name_text_s, $2.line_s, 
$2 .Stbl names i); 
mk_simple dec] io($$.ip_mcemxref, $$.d_error_s, $2.name_text_s, 
$2.xref_ value _s); 


'symbol table 

S2 acon i =o 

$2.env_i = CONCEPT CLASS]; 
stb] build3($2, $4, $5); 
passon stbl3(s2, $4, $3). 


iMasability information 
passdn 2($2, visible types, visible names); 
passovr2x 2(S2, $4, $5, visible types, visible names); 


'error messages -- incomplete for now... 
S$$.error msgs_s = [$$.d error_s, $2.error_msgs_s, $4.error msgs s, 
$5.error_msgs_s); 


} 
| CONCEPT formal _ name formal_arguments where VALUE value arguments where 
' functions, defined with preconditions and postconditions 
{ 
sswlocal types s = { (2? : string =: UNDEFINED TYPE) }; 


passup i($2, xref value); 
$$.d_error_s = check_complex_decl]($5$.ip_memxref_i, $2.name_text_s, 
$3.name_fargs_s, $2.line_s, $$.stbl_names_ i); 
mk complex _decl($S.ip_mcmxref, $$.d_error_s, $2.name_text_s, 
$2.xref value_s, $3.name_fargs_s); 


‘symbol table 


$2.args i = $3.args_text_5s; 
S2.eny 2 = CONCEPT CLASS2; 
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passovr 1($2, $6, xref_value); 
stbl_buildS($2, $3, $4, $6, $7); 
passdn_stb15($2, $3, $4, $6, $7); 


!'visibility information. 

passdn 2($2, visible_types, visible names) ; 

passovr 2($2, $3, visible types, visible_names); 
passovr2x 2 ($3,5$4,$6, visible types, visible names) ; 
passovr_2($6, $7, visible_types, visible names); 


ferror messages -- incomplete for now... 
$$.error_msgs_s = [$$.d_error_s, $2.error_msgs_s, $3.error_ msgs 5&, 
$4.error_msgs_s, $6.error_msgs_s, $7.error msgs s]; 


value_arguments ! a new nonterminal to simplify equations. 
: formal arguments 
{ 
!'symbol table 
passiol 3($1, ip_stbl_ class, ip _stbl_ names, ip _stbl_ params); 
passdn_1($1, ip_stbl_ result); 
$5.ip_stbl_result_s = (Sl.args_text_s == ™" 
=> S$1.ip stblrecultrs 
# Sl.ip stbl result s +| 
{($$.xref_value_i : 
[0 ("2S a rgsetexc rss. el aia 


passdn_ stbll1($1); 


visibility intormat ion 
passiol 2(51, visible types, visible names); 


‘error messages 
passup 1($1l, error_msgs); 


mode] ! data types have conceptual models for values 
MODEL formal_arguments invariant 
{ 
stbl build2($2, $3); 
Passdn stbl2($2, $3); 


'visibility information 
passiol 2($2, visible types, visible names) ; 
passovr 2($2,$3, visible types, visible names) ; 


'error messages 
S$.error_msgs_s = [($2.error_msgs_s, $3.error_msgs s]; 


state ! machines have conceptual models for states 
STATE formal arguments invariant initially 
{ 
stb] build3($2, $3, $4); 
passdn stb1]3($2, $3, $4); 
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‘visibility information 
passiol 2($2, visible_types, visible names) ; 
passovr2x_2($2,$3,$4, visible types, visible names); 


‘error messages 
$$.error_msgs_s = [($2.error_msgs_s, $3.error_msgs_s, $4.error_msgs_s]; 


ze 


invariant ! invariants are true for all states or instances 
: INVARIANT expression list 
{ 
stbl_buildi ($2); 
passdn_stbli($2); 


'visibility information 
passdn 2($2, visible types, visible names); 


ferror_ messages 
passup 1($2, error_msgs); 


"ee 


Phataally ! initial conditions are true only at the beginning 
SeUNTTIALLY expression Jist 
{ 
Stpl buridi(s2); 
passdn_stbli(S$2); 


'visibility information 
passdn 2(S2,visible types, visible names); 


‘error messages 
passup 1($2, error msgs); 


transactions 
° transactions transaction 


{ 
Sto lePundd2 (51,090) + 
passdn_stbi2($1, $2); 


!visibility information 
passio2 2(51,52,visible types, visible names); 


‘error messages 
$$.error_msgs_s = [$l.error_msgs_s, $2.error_msgs_s}; 


stbl]l_buildO(); 
passio0O 2(visible types, visible names); 


'error messages 
$$.error_ msgs s = ""; 


transaction 
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TRANSACTION formal_name EQUALS action list where 
{ 

$2.args_i = ""; 

$2.env_i = TRANSACTION CLASS; 


'symbol table 
stb] build3($2, $4, $5); 
passdn_stbl3(S2, $4, $5); 


iyvisibility information 

passdn_1(S$2,visible types); 

$$.d_error_s = check_simple decl(S$.visible names_i, $2.name_text_s, 
$2.line_s, $$.stbl_ names i); 

mk_simple_decl(S$.visible names i, $$.d_error_s, $2.name_text_s, 
$2.xref_value_s, S$.visible_names_s); 

passovr2x 1($2, $4, $5, visible types); 

passovr2x 1($S, $4, $5, visible_names) ; 


‘error messages 
$$.error_msgs_s = {$2.error_msgs_s, $4.error_msgs_s, $5.error_msgs_s]; 


! Transactions are atomic. 
! The where clause can specify timing constraints. 


action list 
action Vist); section prec SEMI ! sequence 
{ 
StbilybuilaZ (si ees 
passdn_stb12($1, $3); 


fvisibility information 
passdn2 2(51, $3,visible_ types, visible names); 


terror messages 
$$.error _msgs_s = [{$l.error_msgs_s, $3.error_msgs_s]; 


} 
{| action 
{ 
Stbl (puitdi(si); 
passdn_stb11($1); 


(VAST D I Tey ein rOrmac lon 
passdn_2($1, visible types, visible names); 


‘error messages 
passup 1($1, error _ msgs); 


action 


action action %prec STAR ! unordered set of actions 


{ 
Ste lebuildZs ls 
passdn_ stb12($l, $2); 


{visibility information 
passdn2 2($1, $2, visible types, visible names); 


‘error messages 
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} 


$$.error msgs_s = [5l.error_msgs_s, 52.error_msgs_s}; 


IF alternatives FI ! choice 


{ 


stp) build ($2); 
passdn_stbli($2); 


'visibility information 
passdn 2($2, visible types, visible names); 


‘error messages 
passup 1(S$2, error msgs); 


DO alternatives OD ! repeated choice 


{ 


} 


stbl build1($2); 
passdn_stbli($2); 


f'visibility information 
passdn_2($2, visible types, visible names) ; 


lerLOr messages 
passup_1($2, error_msgs); 


| actual name ! a normal message or subtransaction 


{ 


} 


Stbleburlai(s1)+ 
passdn_stbli($i); 


Ivisibility information 
passdn_2($1, visible _ types, visible_names) ; 


lerror messages 
passup 1($1, error_msgs); 


INEXCEP TION actual name ' an exception message 


{ 


alternatives 


stb] buildl ($2); 
passdn stbli($2); 


IVrsioLrlity information 
passdn_ 2($2, visible types, visible names) ; 


lerroru messages 
Passup i(S2, error msgs); 


[woleernatives OR quard action list 


{ 


stb] build3($1, $3, $4); 
passdn_stb13($1, $3, $4); 


fvisibility information 
Passens © 2(5i, 53, $4, visible types, visible names) ; 


'error messages 


se,errc: msgs Ss = [51.e€rror msgs s, $3.ernor mses Ss, 94:¢€2ro0r mses s!; 
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} 
| guard action_list 
{ 
stb] buila2($1 ps2). 
passdn_stbl2(Sl, $2); 


'visibility information 
passdn2_2($1, $2, visible types, visible_names) ; 


'error messages 
$$.error_msgs_s = [$l.error_msgs_s, $2.error_msgs_s]); 


we 


guard 
WHEN expression ARROW 
{ 
stbl_ buildl($2); 
passdn_stbl1($2); 


lvisibility information 
passdn_ 2($2, visible types, visible names); 


‘error messages 
passup 1($2, error_msgs); 


stbl_build0(); 


'error messages 
$$.error_msgs_s = ""; 


temporals 
temporals temporal 


{ 
stbilebuald?2 (Si, °S2); 
passdn_stbl2($l, $2); 


'visibility information 
passio2 2($1, $2, visible types, visible names); 


'error messages 
$$.error_msgs_s = [($l.error_msgs_s, $2.error_msgs_s]; 


stbl_ buildO(); 
passioO 2(visible types, visible names); 


‘Terror messages 
$S.error msgs s = "" 


temporal 
TEMPORAL NAME where response 
{ 


$S.xref_value_s = get_new xref ($2.%text); 
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$4.xref value_i = 


‘symbol table 
Soetpestblyclass ) 


So.1p sti lenames 91 


passovr_2($3, $4, 


$$.xref value s; 


= $$.ip_stbl class i +| 
{($$.xref_value_s : TEMPORAL CLASS) }; 
= $$.ip_stbl names i +| 
{($$.xref_value_s : $2.%text) }; 
ip_stbl_ class, ip_stbl_ names); 


passup 2($4, ip_stbl_ class, ip stbl_names); 


passio2 2($3, $4, 
passdn_stbl2($3, §$ 


ip_stbl_ params, ip stbl result); 
4); 


‘visibility information 


passdn2_1($3, $4, 
$$.d_error_s = che 
$2. 
mk simple decl(S$. 
$$. 
passovr2x_1($$, $3 


‘error messages 
$$.error msgs_s = 


visible types); 

ck_simple decl($$.visible_names_i, $2.%text, 
tline, $$.stbl_ names _ i); 

visible names_i, $$.d_error_s, $2.%text, 
xref _value_s, $$.visible_ names _s); 

» $4, visible_names) ; 


[$$.d_error_s, $3.error_msgs_s, $4.error_msgs_s]; 


Temporal events are trigged at absolute times, 


in terms of the loca 
The "where" describe 


l-elock’ of ‘the actor: 
s the triggering conditions 


in terms of TIME, PERIOD, and DELAY. 


optional formal name 
formal name 


{ 


passup 3($1, name_params, name_text, line); 


passdn 2($1, args, 


env); 


passup 1($1, xref_value); 


!'symbol table 
StD bur iditsl): 
Passan stbli ($1); 


'visibility inform 


at von 


Passiol i 2(si, visible types.) visible names); 


‘error messages 
Passup i(5i, error 


Sone Ss) — 1; 

SS.name_params s = 
$$.name_text_s = " 
S$.xref value_s = 


'symbol table 


omsgs) 


nn. 

¢ 

". 
? 


get_new_xref(S$.args_i); 


° 


add elem(S$.ip stbl_class_i, $$.xref_value_s, $S.env_i, $$.ip_stbl_class s); 
add elem($$.ip_stbl names_i, $S.xref_value_s,$$.args_i, $$.ip_stbl_names_s); 


passio0 2(ip stb] _ 


params, ip stbl result); 
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'visibility information 
passio0O 2(visible types, visible names); 


'error messages 
SS .6LLOL MSC Secu amlan 


formal name 
: NAME formal parameters 
{ 
$$.line_s = $1.%line; 
$$.name_text_s = $1.%text; 
passup_1($2, name_params) ; 
$$.xref_ value_s = get_new_xref($1.%text); 


'symbol table 
$$.signature_s = ( $§$.args i == "®) 
-> mn 
#17 (", Ss$.args 1, 2)" J; 
add elem($$.ip_ stbl_¢class_i, $$.xref_value_s, $$.env_i, $2.ip stb! clascmia 
add_elem($$.ip_stbl_names_i, $$.xref_value_s, 
$1.%text “* $$.signature_s, $2.ip _stbl_ names_i); 
add elem($S$.ip_stbl params_i, $$.xref_ value_s, $2.name_params_s, 
$2.ip_stbl_params_i); 
passdn 1($2, ip stb] result), 
passup_ 4($2, ip_stbl_class, ip_stbl_names, ip_stbl_params, ip_stbl_ result); 
passdn_stbl1($2); 


! visibility information 
passiol 2($2, visible types, visible names) ; 


'error messages. 
Passup i(S2, error msgs); 


formal parameters ! parameter values are determined atespeei! veartionei nce 
‘{’ field list '}’ where 
{ 


$$.name_params_s = $2.fieldpattern_s; 


'symbol table 
stb] build2($2, $4); 
pasedn Stbl2 (52, 54); 


1 visibility information 
passiol 2(S$2, visible types, visible names); 
passovr 2(S2, $4, visible _ types, visible names); 


'error messages. 
S$.error msgs _s = [$2.error_msgs_s, $4.error_msgs_s]; 


$$.name_params_s = NULL STRING; 


'symbol table 
Stoll bur a0); 
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"visibility intermatzon 
passio0Q 2(visible types, visible names) ; 


! error messages 
$$.error msgs s = ""; 


formal arguments ! arguments are evaluated at run-time 
C woteld list *)* 
{ 
$$.name_fargs_s = $2.fieldpattern_s; 
$S.args text _s = $2.text_s; 


'symbol table 
Sr Daputldi(s2); 
passdn_stbli($2); 


fvisibility information 
passiol 2($2, visible types, visible names); 


'error messages 
passup_ 1($2, error msgs); 


$$.name_fargs s = ""; 
SS-args text s = °"> 


'symbol table 
stbl_ build0Q(); 


Ivisibility information 
passio0 2(visible types, visible names) ; 


ferror messages 
$$.error msgs s = ""; 


field list 
: field list ’,’ field 
{ 


$$.fieldpattern s = {$l.fieldpattern s, ELEM DELIMITER, 
$3.fieldpattern_ s); 
So.text s = (Sl.text 5s, ™, ", 53.text s]; 


'symbol table 
stbl build2($1, $3); 
passdn_stbl2($1, $3); 


{visibility information. 
passio2 2($1, $3, visible types, visible names); 


‘error messages 
$$.error msgs_s = (S$l.error_msgs_s, $3.error_msgs_s); 
} 
| field 
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Se 


field 


: declname list ’: 


{ 


} 
oat 
{ 


passup 2($1, fieldpattern, text); 


'symbol table 
stbl_ buildl($1); 
passdn_stbli($1); 


'visibility information 
passiol 2($1, visible types, visible names); 


Terror messages 
passup_1($1, error_msgs); 


¢ 


type _spec 


S$l.name_type text_i = $3.type_name_text_s; 
$$.text_s = [S$l.text_s, " : ", $3.type name _text_s]); 


S$i.name_type_ value_i = $3.type name _value_s; 
passup 1($1, fieldpattern) ; 


!symbol table 
stbl build2($1, $3); 
passdn_stbl2($l, $3); 


iyvisibility-information. 
passiol 2(2i1, visible types, visible names); 
passdn 2($3, visible types, visible names) ; 


'error messages 
$$.error_msgs_s = [$l.error_msgs_s, $3.error_msgs_s}; 


NAME ’:’ type spec 


$5.rieldpattern s = ["5", S2.ttext, ~:")54-Cype manemvalveucal, 
$$.text_s = ["S", $2.%text, " :; ", 54.type name text s]; 


‘symbol table 

$$.xref value s = get new xref ($2.%text); 

add_ elem($$.ip_stbl_ class i, $$.xref_value_s, VARIABLE CLASS, 
$4.ip_stbl_class_i); 

add elem(S$.ip stbl names i, $$.xref value_s, "$"°S2.%text, 
$4.ip_stbl names _ i); 

add_elem(SS.ip_stbl result_i, $$.xref_value_s, $4.type_name_ value _s, 
$4.ip_stbl result i); 

passdn_1($4, ip_stbl_ params); 

passup_ 4($4, ip_stbl class, ip_stbl_names, ip _stbl_ result, ip_stbl_ params); 

passdn stbl1($4); 


‘visibility information 
$$.visible types s = ($4.type name_value_s == SPEC_LIBRARY_ MODULE type) 
-> $$.visible types i +] 
{(SZ.ttext +: [SZettbext, "eC" 
". locals |) } 
# $$.visible types i; 
$$.d_error _s = check_simple decl($$.visible names i, $2.%text, 
$2.%line, $5.stbl names i); 
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mk_ simple _decl_io(S$.visible_names, $$.d_error_s, $2.%text, $$.xref_value_s); 
passdn_1($4, visible_types); 
passovr_1($$, $4, visible_names); 


ferror messages 
$$.error_msgs_s = [$$.d_error_s, $4.error_msgs_s}; 
} ; 
| QUESTION MARK 
{ 
$$.fieldpattern_s = "?"; 
So SOMES = alas 


{symbol table 
stbl_build0(); 


ivisibility information 
passioO l(visible types); 


‘error messages 
$$.error msgs_S = error message (UNRESOLVED TYPE, $1.%line); 


type_spec 
actual name ! name of a data type 
{ 
S$.type_name_text_s = $l.actual_name_text_s; 
$$.type_name_value_s = $$.visible types_i ($l.actual_name_text_s); 


'symbol table 
Stpl builal(s1); 
passdn_stb11($1); 


'visibility information 
passdn_ 2($1, visible types, visible names); 


'error messages 
$$.tmp_msg = error_message (UNDECLARED TYPE, $l.line_s, 
Sl.actual_name_text_s); 
$$.error_msgs_s = ($$.visible types_i ($]l.actual_name_text_s) 
UNDEPINED TYPE) 
-> $$.tmp_msg 


te; 
} 
| QUESTION MARK 
{ 
Seat ype mame texts = 72"; 
95.type name value_s = *?"; 


'symbol table 
stbi_ build0O(); 


'error messages 
$$.error msgs _S = error message (UNRESOLVED TYPE, 31.%line); 


iow 


° 
? 


' This structure was added so that a name list used for declarative 
! purposes (e.g. in a field) could be easily distinguished from a name list 
! used in an applicative structure (e.g. imports, export, hide). 
! This lessened the actual attribute load of the name_list structure. 
declname_ list . 
: declname_list NAME 
{ 

$$.xref_ value_s = get_new xref($2. %text); 

$$.text_s = [Sl.text*s, " ", $2-%Bext]; 

passdn 2($1, name_type_value, name_type text); 

$$.fieldpattern_s = [ $l.fieldpattern_s, ELEM DELIMITER, 

$2.%text, ":", $$.name_type_value_ i ]; 


'symbol table 

passdn_4($1l, ip_stbl_ class, ip_stbl_names, ip_stbl_result, ip_stbl_ params); 

add_elem($l.ip_stbl_class_s, $$.xref_value_s, VARIABLE CLASS, 
$$.ip_stbl_class_s); 

add_elem($1.ip_ stbl_ names_s, $$.xref_value_s, $2.%text, $5.ip_stbl_ names s); 

add elem($l.ip_ stbl_ result_s, $$.xref_value_s, $$.name_type_ value i, 
$$.ip_stbl result _s); 

passup _1($l, ip _stbl_ params); 

passdn_ stbl1($1); 


‘visibility information 

passdn_2($l, visible types, visible names); 

$$.d_error_s = check simple decl ($l.visible names_s, $2.%text, 
$2.%line, $$.stbl_ names_i); 

mk simple decl($l.visible names_s, $$.d_error_s, $2.%text, 
$$.xref value_s, $$.visible names _s); 


$S.visible types _s = (S5$.name_type_text_i == SPEC LIBRARY MODULE type) 
-> $1. visible types s +| 
{($2.%text : [$2.%text, "@", 


ni Socal an) 
# Sl.visible types ‘s; 


$$.error_msgs_s = [(Sl.error_msgs_s, $$.d_error_s]; 
} 
| NAME 
{ 
$$.xref_value_s = get _new_xref(S$l. %text); 
s$.fieldpattern s = [{[Sl1.8text, ":", $S$.name type value 1); 


S$.text_s = S1.8text- 


‘symbol table 

add_elem(SS.ip stbl class_i, $$.xref_value_s, VARIABLE CLASS, 
$$.ip_stbl_ class _s); 

add_elem(SS$.ip_stbl_ names_i, $$.xref_value_s, $l.%text, $$.ip_stbl_names_s); 

add_elem($S.ip_ stbl_result_i, $$.xref_value_s, $$.name_type_value i, 
$$.ip_stbl_result_s); 

passioO 1l(ip_stbl_ params); 


'visibility information 
! -- eventually need to make local with module name... 


SS$.visible types _s = ($$.name_type text_i == SPEC _LIBRARY_MODULE type) 
=? $$. visible types i +| 
((Slostext=: {$1 Astext, "8", 


“aaloeal™.))) 
# $S.visible types i; 


$$.d_error_s = check_simple_decl($$.visible names i, $1.%text, 


$1.%line, $$.stbl_ names i); 


mk_simple_decl_ io($$.visible names, $$.d_error_s, $1l.%text, 


$$.xref_value_s); 


$$.error_msgs_s = $$.d_error s; 


=e 


name list 
: mame list NAME 
ee 
| NAME 
i) 


optional actual _ name 
actual name 


{ 


passup_4($1, actual_name_text, actual params, full _ name, 


Stbiebusi1di (Si). 
passdn_stbli1($1); 


'visibility information 
passdn_2($1, visible types, visible names); 


ferror messages 
Ppassup (Sl, error msgs): 


$$.line_s = -1; 
$$.actual name _text_s = ""; 
$$.actual params _s = ""; 
$$.-full name _s = ""; 


Sep ilyous lao); 


‘error messages 
$$.error msgs s = ""; 


actual name 

NAME actual parameters 

{ 
$$.actual_ name _text_s = $1.%text; 
$9-line_s = $1.%line; 
passup_1($2, actual params) ; 
$$.full_name_s = ($2.actual_ params_s == "") 

=> Sl.#text 


# [S$1.%text, "{", $2.actual params _s, 


'symbol table 
stb] buildl ($2); 
passdn stbll($2Z); 


hess 


line); 


i'visibi lity information 
passdn_ 2($2, visible types, visible names) ; 


‘error messages 
passup_1($2, error_msgs); 


actual parameters ! parameter values are determined at specification time 


: °{’ arg list ’}? 


$$.actual params_s = $2.arglist_text_s; 


stbl_ buildl ($2); 
passdn_stbl1($2); 


‘visibility information 
passdn_ 2($2, visible_types, visible_names) ; 


'error messages 
passup 1($2, error_msgs); 


%prec SEMI ! must have a lower precedence than ” {’ 
$$.actual params _s = ""; 
stbl buildd(); 


!error messages 
$$.€rror msgs 5 = 95"; 


actual arguments ! arguments are evaluated at run-time 


arg 17st 


arg list. ”)* 


$$.full_args s = ($2.arglist text_s == ™") 


-> nmr 


# ["(", S2.arglist. text s7m4), 


Sstblebuildil (52); 
passdn_ stbll ($2); 


Visibility information 
passdn_ 2($2, visible types, visible names); 


‘error messages 
passup 1($2, error msgs); 


tprec SEMI ! must have a lower precedence than ’” (’ 
stb] build0O({); 


‘error messages 
$$.error_ msgs_s = ""; 


arg list. arg tprec COMMA 
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SS$.arglist_text_s = (Sl.arglist_text_s, ACTUAL _DELIM, $3.arg text_s]; 


stbl_build2($1, $3); 
passdn_stb12($1, $3); 


visibility information 
passdn2 2($1, $3, visible types, visible names); 


‘error messages 
$$.error _msgs_s = ($l.error_msgs_s, $3.error_msgs_s); 


$$.arglist_text_s = 5l.arg text_s; 


stbl_ buildl($1); 
passdn_ stbl1($1); 


'visibility information 
passdn_2($1, visible_types, visible names); 


ferror_ messages 
passup Itsl, error msgs); 


arg 
: expression 
{ 
$$.arg text_s = $l.xten_type_s; 


Sep but lal (Si) 5 
passdn stbl1($1); 


'visibility information 
passdn_2(51, visible types, visible_names); 


‘error _messages 
passup 1($1l, error msgs); 
} 
| pair 
{ 
$$.arg text s = $1.xten_type s; 


Sstbil build! ($1); 
passdn_stb11($1); 


Myisibility information 
passdn_ 2(S1, visible types, visible names); 


!error_ messages 
passup 1($1, error_msgs); 


expression list 
expression list ’,’ expression tprec COMMA 
{ 
' all types in an expression list must be the same 
$$.xten type s = $i.xten type s; 


15) 


stbl build2($1, $3); 
passdn_stbl2($l, $3); 


visibility information 
passdn2 2($1, $3, visible types, visible names); 


'error messages 


$$.error_msgs Ss = ([$l.error msgqs¥s,93.error msgs us), 


} 


| expression prec COMMA 
{ 


passup_1($l1, xten_type); 


stbi (builidl (91); 
passdn_stbl1($1l); 


'visibility information 
passdn_2($1, visible_types, visible names); 


ferror_messages 
passup _1($l, error_msgs); 


expression 
: quantifier ’(’ field list restriction BIND expression ’)’ 
{ 
$$.xten_type_s = ":boolean"; 


stbl_ build3($3, $4, $6); 
passdn_stbl13($3, $4, $6); 


‘visibility information 
passdn3 2(53, $4, $6, visible types, visible names) ; 
‘error messages 


S$.error msgs_s = [S3.error_msgs_s, $4.error_msgs_s, $6.error_msgs s]; 


} 
| actual mame actual arguments 


{ 


$$.xten_type_s = [REF SYMBOL, $1.full_name_s, $2.full_args_ s); 


stbl build? (31, 52); 
passdn_stbl2($1l, $2); 


‘visibility information 


passdn2 2($1, $2, visible types, visible names); 


ferror messages 


$$.error_msgs_s = (Sl.error_msgs_s, $2.error_msgs_s}; 


) 


| actual mame ’@’ actual_name actual _arguments 
{ 
$$.xten_type_s = [REF SYMBOL, $1.full_name_s, "@", $3.full_name_s, 
$4.full args s]}; 


stbl builds (sis oo 
passdn stb13(51, $3, $4); 
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'visibility information 
passdn3 2(51, $3, $4, visible types, visible names); 


‘error messages 
$$.error_msgs_s = [S$l.error_msgs_s, $3.error_msgs_s, $4.error_msgs_s]; 
} 
{ NOT expression prec NOT 
{ 


$$.xten_type_s = [REF_SYMBOL, $1.%text, "(", $2.xten_type_s, ")"]; 


Stol buildi(s?)-; 
passdn_stbl1 ($2); 


!'visibility information 
passdn_2(S2, visible types, visible names); 


ferror_ messages 
passup 1($2, error_msgs); 
} 
| expression AND expression &%prec AND 
{ 
S$.xten_type_s = {REF_SYMBOL, $2.%text, "(", S$l.xten_type s, 
ACTUAL DELIM,$3.xten_type_s, 7)" J; 


stole build2($l, 33); 
passdn_stbl2(S1, $3); 


‘visibility information 
passdn2_ 2($1, $3, visible types, visible names); 


‘error messages 
$$.error msgs_s = {$l.error_msgs_s, $3.error_msgs_s]; 
} 
| expression OR expression $tprec OR 
{ 
S$.xten_ type s = [REF SYMBOL, $2.%text, "(", $l.xten_type s, 
ACTUAL DELIM,$53.xten_type _s, ")" J; 


Sepioutlaz(S1,s3)7 
passdn stbl2($l1, $3); 


fvisibility information 
passdn2 2($1, $3, visible types, visible names); 


'error messages 


$S$.error msgs_s = {$l.error_msgs_s, $3.error_msgs_s]; 
} 
{| expression IMPLIES expression prec IMPLIES 
{ 
$$.xten_type s = [REF_SYMBOL, $2.%text, "(", Sl.xten_type _s, 


ACTUAL _DELIM,$3.xten_type_s, ")" J; 


Stole build2 (sl, $3).; 
passdn_stbl2($1, $3); 


'visibility information 
passdn2 2($1, $3, visible types, visible names); 


'error messages 
$$.error msgs s = [Sl.error msgs _s, $3.error_ msgs s}; 


sy 


} 


| expression IFF expression tprec IFF 
{ 
$$.xten type S =*[REF SYMBOL, S2.Atext, "(", Si.xten types, 
ACTUAL DELIM,$3.xten type _s, ")" J; 


stbl_build2($1, $3); 
passdn_stbl2($1l, $3); 


'visibility information 
passdn2 _2($1, $3, visible types, visible names); 


‘error messages 
$$.error msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 
} 
| expression LT expression {prec LE 
{ 
$$.xten_ type s = [REF SYMBOL, "<" , "(", $l.xten_type s, 
ACTUAL_DELIM, $3.xten_type_s, ")" J; 


Stole Dudd2(51,— 55). 
passdn_stbl2($1, $3); 


'visibility information 
passdn2 2($1, $3, visible types, visible names) ; 


‘error messages 


9>.@€rror msos 9s — ([Sl.error msgs °s, 53.erconemsgs sl 
} 
| expression GT expression prec LE 
{ 
$$.xten_ type s = [REF SYMBOL, ">", “(", Si.xten Cypers, 


ACTUAL_DELIM,$3.xten_ type_s, ")" ]; 


Stbi obuaid2 ($1,453). 
passdn stbi2(Sl1," $3); 


i'Visibility intormation 
passdn2_2(51, $3, visible types, visible names); 


‘error messages 


$$.error_msgs_s = [$l.error msgs_s, $3.error_msgs_s]; 
} 
| expression EQUALS expression prec LE 
{ 
$5.xten_ type s = [REF SYMBOL, "=", "%(", Sl.xten typers, 


ACTUAL DELIM,95-xcen type Ss, “) al, 


stbl build2(51, $3); 
bassdnestbhi2 (515. $3) 


'visibility information 
passdn2_2(51, $3, visible types, visible names); 


'error messages 


$$.error_msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 
} 
| expression LE expression %prec LE 
{ 
$$.xten_type_s = [REF_SYMBOL, $2.%text, "(", $1.xten_type s, 


ACTUAL DELIM,$3.xten_type_s, ")" J; 
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stbl build2($1, $3); 
Passdn st biz (51, 55377 


'visibility information 
passdn2_ 2($1, $3, visible types, visible names); 


‘error messages 


$$.error msgs_s = [$l.error_msgs_s, $3.error_msgs_s]}; 


} 
| expression GE expression &prec LE 
{ 
$$.xten_type_s = [REF_SYMBOL, $2.%text, "(", Sl.xten_type_s, 
ACTUAL_DELIM,$3.xten_type_s, ")" J>; 


stbl buildz(Si, 93) 7 
passdn_ stbl2($1, $3); 


'visibility information 
passdn2 2($1, $3, visible_types, visible_names); 


'error messages 


$$.error msgs _s = (Sl.error msgs_s, $3.error_msgs_s]}; 


} 
| expression NE expression $prec LE 
{ 
oo RUeMme ype S — [REF (SYMBOL, S2.ttext, 741, o)-xXten types, 
ACTUAL DELIM,$3.xten_type_s, ")" J; 


St bl Bui laz (32,353); 
passdn_ stb12($1, $3); 


Ivisibility information 
passdn2 2($1, $3, visible types, visible names); 


ferror messages 


$$.error msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 


expression NLT expression 


{ 


| prec LE 


$$.xten_ type s = [REF SYMBOL, $2.%text, "(", $l1.xten type _s, 
ACTUAL _DELIM,$3.xten_type_s, ")” ]; 


Seb eouite2 (Si; ass) 
passdn_ stbl2($1, $3); 


ivaisibility information 


passdn2_2($1, $3, visible _ types, visible names); 


‘error messages 


$$.error msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 


} 


| expression NGT expression tprec LE 


{ 


$$.xten_type_s = [REF SYMBOL, $2.%text, "(", Sl.xten_type_s, 
ACTUAL DELIM,$3.xten_type_s, ")" J; 


stbl build2($Sl, $3); 
passdn_stbl2($1, $3); 


PTVsiollicy information 


Ie) 


passdn2 2($1, $3, visible types, visible names); 


ferror messages 


$$.error_msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 
) 


{ expression NLE expression &prec LE 


{ 


$$.xten_type_s = [REF_SYMBOL, $2.%text, "(", S$l.xten_type s, 
ACTUAL DELIM,$3.xten_type_s, ")" ]J3 


stbl build2($1, $3); 
passdn_stbl2($1, $3); 


'visibility information 
passdn2_2($1, $3, visible _types, visible names); 


‘error messages 


$$.error_msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 


} 
| expression NGE expression &%prec LE 
{ 
$$.xten_type_s = [REF SYMBOL, $2.%text, "(", $l.xten_type s, 
ACTUAL _DELIM,$3.xten_type_s, ")" J; 


stbl_ build2($1, $3); 
passdn_stbl2($l, $3); 


{visibility information 
passdn2_ 2($1, $3, visible types, visible_names); 


ferror messages 


$$.error_msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 


} 
| expression EQV expression prec LE 
{ 
$$.xten_type_s = [REF_SYMBOL, $2.%text, "(", $l.xten_type s, 
ACTUAL _DELIM,$3.xten_type_s, ")" J; 


stbl build2($1, $3); 
passan Stbli2i{si, 33); 


'yvisibility information 
passdn2_2($1, $3, visible types, visible names); 


ferror messages 


$$.error msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 


} 
| expression NEQV expression tprec LE 
{ 
$S.xten_type_s = [REF_SYMBOL, $2.%text, "(", $l.xten_type_s, 
ACTUAL _DELIM, $3.xten_type_s, ")" J; 


Stbiv buiita2 (61. S32). 
passdn_ stbl2($1, $3); 


'visibility information 
passdn2 _ 2($1, $3, visible types, visible names); 
'error messages 


$$.error_msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 


160 


| MINUSMARK expression prec UMINUS 
{ 


SS. xceretyoOemsm=nREr sYMBOL, "-", ™=(", 


$2.xXBGn Cyperus, “~)oi 


stbl buildi(s2)¢ 
passdn_stbll ($2); 


!visibility information 
passdn_2($2, visible types, visible names); 


ferror_ messages 
passup_1($2, error msgs); 
} 
| expression PLUSMARK expression $prec PLUS 
1 
$$.xten_type_s = [REF SYMBOL, "+", "(", $1.xten_type 5s, 
ACTUAL_DELIM,$3.xten_type_s, ")" J; 


stbl build2($1, $3); 
passdn stbl2($1, $3); 


‘visibility information 
passdn2_2($1, $3, visible types, visible_names); 


'error messages 


$$.error_msgs_s = {$l.error_msgs_s, $3.error_msgs_s}; 


} 


| expression MINUSMARK expression &prec MINUS 
{ 


$$.xten_type_s = [REF_SYMBOL, "-", "(", $l.xten_type_s, 
ACTUAL_DELIM,$3.xten_type _s, ")" J; 


stbl build2($1, $3); 
passdn stb12($1, $3); 


{visibility information 
passdn2_2($1, $3, visible types, visible names); 


ferror messages 


$$.error_msgs_s = (Sl.error_msgs_s, $3.error_msgs_s]; 


} 
| expression STARMARK expression prec MUL 
{ 


S9.xten type s = {REF SYMBOL, "*", ™(", Sl.xten type s, 
ACTUAL_DELIM, $3.xten_type_s, ")" J; 


stbl_ build2($1, $3); 
Passanestol7Z (Si,, o2)). 


{visibility information 
Passan2 2(s1, $3, visible types, visible rnames) ; 


'error messages 


$$.error_msgs_s = {$l.error_msgs_s, $3.error_msgs_s}; 


} 


| expression SLASH expression prec DIV 


{ 
$$.xten type s = {REF SYMBOL, “/", "(", 5l.xten_type s, 
ACTUAL DELIM,53.xten_type_s, ")" J; 
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stbl build2($l, $3); 
passdn_ stbl2($1, $3); 


‘visibility information 
passdn2_2(51, $3, visible types, visible names); 


‘error messages 
$$.error_msgs_s = [S$l.error_msgs_s, $3.error_msgs_s]; 
) 
| expression MOD expression %prec MOD 
{ 
$$.xten_type_s = [REF_SYMBOL, $2.%text, "(", $l.xten_type_s, 
ACTUAL_DELIM,$3.xten_type_s, ")" J]; 


stblabuild2( $1, $3); 
passdn_ stbl2($l, $3); 


visibility information 
passdn2 2($1, $3, visible types, visible names); 


'error messages 
$>.e€rror msgs s = [Sl 2érror msgqsis, 53-ercoremsdses |, 
} 
| expression EXP expression prec EXP 


{ 
$$.xten_type_s = [REF_SYMBOL, $2.%text, "(", $l.xten_type _s, 
ACTUAL _DELIM, $3.xten_type_s, ")" J; 


stb build2 (S175 s31; 
passdn_ stbl2($l1, $3); 


Ivisibility information 
passdn2 2($1, $3, visible _ types, visible names); 


'error messages 
S$.error_msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 


} 
| expression U expression prec U 
{ 
SS$.xten_type s = [REF_SYMBOL, $2.%text, "(", $l.xten_type s, 
ACTUAL_DELIM, $3.xten_type_s, ")" J; 


stbl_build2($1, $3); 
passdn stbl2(Sl, $3); 


'visibility information 
passdn2_2($1, $3, visible types, visible names) ; 


ferror messages 


S$.error_msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 


} 


| expression APPEND expression %prec APPEND 
{ 


S$.xten_type_s = [REF SYMBOL, $2.%text, "(", $l.xten_type_s, 
ACTUAL DELIM,$3.xten_type_s, ")" J; 


stbl buoald2(si 7 3). 
passdn_stbl2($1, $3); 


ivisibility information 
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passdn2 2($1, $3, visible types, visible_names) ; 


ferror messages 


$$.error msgs_s = [$l.error_msgs_s, $3.error_msgs_s]; 


} 
| expression IN expression &prec IN 
{ 
$$.xten_type_s = [(REF_SYMBOL, $2.%text, "(", $l.xten_type s, 
ACTUAL _DELIM, $3.xten_type_s, ")" J]; 


Bebl build? (si, $3); 
passdn_stbl2($1, $3); 


ivisibality information 
passdn2 2($1, $3, visible types, visible names); 


'error messages 


$$.error msgs_s = ($l.error_msgs_s, $3.error_msgs_s]; 


} 
| STARMARK expression &prec STAR 
' *x is the value of x in the previous state 


{ 
$$.xten_ type s = S2.xten_type_s; 


Sstbly buildl(s2) ; 
passan stbli($Z); 


'wisibality wnformat ion 
passdn 2($2, visible types, visible names); 


‘error messages 
passup 1($2, error_msgs); 


} 


ie So -express ion &prec DOT 
! $x represents a collection of items rather than just one 
' sl = {x, $s2} means sl = union({x}, s2) 
' sl = [x, $s2] means sl = append([x], s2) 


{ 
oo = em types — S2.xten types; 


Seoimeui dl ($2) ; 
passdn_stbli($2); 


Visibility information 
passdn 2($2, visible types, visible names) ; 


'error messages 
passup_1($2, error msgs); 
} 
| expression RANGE expression & prec RANGE 
Mexetivelia. «2 Ol Lif ic in {a.: bl) itt a <=) x <= 
' [a .. b) is sorted in increasing order 


$$.xten type _s = [REF SYMBOL, $2.%text, "(", $l.xten_type s, 
ACTUAL _DELIM,$3.xten type_s, ")" J; 


Sseplobuildaz(s1, $3)4 
passdn stbiz($l, $3); 
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'visibility information 
passdn2_2($1, $3, visible types, visible names) ; 


‘error messages 
$$.error_msgs_s = [$l.error_msgs_s, $3.error_msgs_s}; 


} 
| expression DOTMARK NAME prec DOT 
{ 
$$.xten_type_s = [REF_SYMBOL, ™.", "(", S$l.xten_type_s, 
ACTUAL DELIM, "\"")  s3attext, “\roe died 


stbl_ buildl($1); 
passdn_stbl1($1); 


'visibility information 
passdn 2($1, visible types, visible names); 


ferror messages 
passup 1($1, error msgs); 
} 
| expression LBRACK expression ’}’ %prec DOT 
{ 
$$.xten_type_s = [REF SYMBOL, "[", "(", $l1.xten_type s, 
ACTUAL _DELIM, $3.xten_type_s]; 


stbl puild2(sl, $23); 
passdn_stbl2($1, $3); 


‘visibility information 
passdn2 2($1, $3, visible types, visible names); 


‘error messages 
S29 s€rrOr msgs s = "(Sl .error msgs 7s, >) senr-orenscs.s |, 
} 
| °(’ expression ‘)’ 
{ 
passup_ 1($2, xten_ type); 


stb! builal(s2); 
passdn_stbl1(S$2); 


lvisibilaty imntermation 
passdn 2(S$2, visible types, visible names); 


ferror messages 
passup 1($2, error msgs); 
} 


i ’(* expression NAME ‘)’ ! expression with units of measurement 


! standard time units: NANOSEC MICROSEC MILLISEC SECONDS MINUTES HOURS DAYS 


WEEKS 
passup 1($2, xten_type); 


Sth i ybuilai= 2) 
passdn_stb11 ($2); 


'visibility intermation 
passdn_2($2, visible types, visible names) ; 


164 


‘error messages 
passup 1($2, error msgs); 


| TIME ! The current local time, used in temporal events 
{ 
$$.xten type s = "sreal"; 


stbl buildd(); 


‘error messages 


$$.error_msgs_s = ""; 
} 
| DELAY ! The time between the triggering event and the response 
{ 
$$.xten_type_s = ":real"; 


stbl buildd{) ; 


'error messages 
$$.error msgs s = "™"; 


} 


| PERIOD ! The time between successive events of this type 
{ 


$$.xten_ type _s = ":real"; 
stbl_ build0d(); 


'error messages 
$$.error_msgs_s = ""; 
} 
| literal 
{ 
Passup 1(51, xten type); 


Stbl buildi(si); 
passdn stbll($1); 


visibility information 
passdn 2($1, visible types, visible names); 


‘error messages 
passup _1($1l, error_msgs); 


} 
| literal ’@’ actual _ name ! literal with explicit type 
{ 
l*** unsure about this one. 
passup 1(3l1, xten type): 


Sebi bun ba2(Sl7 $3): 
passdn stbl2($l, $3); 


Visibility information 
passdn2 2($1, $3, visible types, visible names) ; 


‘error messages 


$$.error_msgs_s = [$l.error_msgs_s, $3.error_msgs_s}; 


eres ' An undefined value to be specified later 
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SS=uxten, type. star" 27; 


stb] _buildd(); 


'error messages 
$$.error msgs_s = ""; 


! An undefined and illegal value 


$$.xten_type_s = "3!" 
stb] buildd(); 

lerror messages 
$$.error msgs_s = ""; 


} 


| IF expression THEN expression middle cases ELSE expression FI 


{ 


$$.xten_type_s = $4.xten_type s; 


stbl_build4($2, $4, $5, $7); 
passdn_stbl4($2, $4, $5, $7); 


'visibility information 


passdn4 2(S2, 


$4, $5, $7, visible_types, visible names); 


‘error messages 
$$.error_msgs_s = [$2.error_msgs_s, $4.error_msgs_s, 


middle cases 


: middle cases ELSE 


quantifier 


{ 


$5.error msgs_s, $7.error_msgs_s]; 


IF expression THEN expression 


Stbiebui1e3517 23.020). 
passdn_ stb13($1, $3, $5); 


‘visibility information 


passdn3 2($1, 


$3, $5, visible types, visible names) ; 


‘error messages 


$$.error msgs_s = [$l.error_msgs_s, $3.error_msgs_s, $5.error_msgs_s); 


StDiebuitdl(); 


'error messages 


$$.error msgs_s 
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i 

| SUM 
ee, 

| PRODUCT 
(7) 

| SET 
{ } 

| MAXIMUM 
Ld 

| MINIMUM 
{ } 

| UNION 
{ } 

| INTERSECTION 
oe 


Beseriction 
: SUCH expression 
{ 
stbl buildl($2); 


lvisibility information 
passdn 2($2, visible _ types, visible_names) ; 


ferror_ messages 
passup 1($2, error_msgs); 


Stoll buildd (); 


ferror messages 
Bo-e€rror msgs 5 = 7"; 


literal 
INTEGER LITERAL 
{ 


$$.xten_type_ s = ":integer"; 


stbl_ buildO(); 


‘error messages 
$$.error msgs _ §s ve 


) 
REAL) LATERAL 


{ 


$$.xten_type_s = ":real"; 
Stbil buileo(); 


'error messages 
$$.error msgs _s = ""; 
} 
| CHAR LITERAL 
{ 


So. xben type Ss = ":char”; 


stbl buildd(); 
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} 


'error messages 
$$.error msgs _s = ""; 


| STRING LITERAL 


{ 


SiS -xten_type_s = “est ring” ; 
stbl_build0(); 


'error messages 


$$.error_msgs_s = °"; 
| es NAME ! enumeration type literal 
| $$.xten_type_s = “:enumeration"; 
stbl_buildd(); 
‘Terror messages 
$$.error msgs s = “"; 
| ae expressions ’]’ ! sequence literal 
| $$.xten_type_s = [":sequence{",$2.xten_type_s, "}"J; 


stbl_buildl ($2); 
passdn_stbl1l1 ($2); 


'visibility information 
passdn 2($2, visible types, visible names) ; 


ferror messages 

passup 1(52, error msgs); 

expressions ’}’ ! set literal 
SS.xtenctype Ss = [/™scet{ 7, S2.xten type Ss, ajo. 
Stole buildi(s2); 

passdn_ stbl1($2); 


visibility information 
passdn 2($2, visible types, visible names); 


ferror messages 
passup 1($2, error _ msgs); 


expressions ’;’ expression ’ }’ ' map literal 


$$.xten_type_s = ["map{", $2.xten_type_s, ACTUAL_DELIM, 


$4.xten_type_s, "}"]; 


Stbl ybuild24s27 54); 
passdn stbi2($2, $4); 


ivisibility information 
passdn2_ 2($2, $4, visible types, visible names); 
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‘error messages 


$$.error_msgs_s = [$2.error_msgs_s, $4.error_msgs s]; 
| LBRACK pair list °)’ Y tuple literal 
{ 
$9.xten type s = [ “Cuple(", $2.xven_type s, "}"]; 


Stbhl buildl(>2); 
passdn_stbli ($2); 


visibility information 
passdn_2($2, visible types, visible names); 


ferror_ messages 
passup 1($2, error_msgs); 


me i pair’) ! one_of literal 
$$.xten type _s = $2.type_ s; 
Sto l sbuilel(s2); 
passdn_stbll1($2); 


ivisibility information 
passdn_ 2($2, visible types, visible names) ; 


ferror messages 
passup 1($2, error_msgs) ; 


' relation literals are sets of tuples 


expressions 
expression list 
{ 
passup 1($1, xten type); 


Scot ebuTlai(s1); 
passdn_stbl1($1); 


ivasibility information 
passdn 2($l, visible types, visible names); 


Vetlor messages 
passup 1($1, error msgs); 


$$.xten type s ptt 


stbl_ build0O(); 


‘error messages 
$$.error msgs_s = ""; 
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pair list 
paic List “2 pair 
{ 
$$.xten type s = {$l-xten_CtCypete,, PAIR DELIM, Ss xtenltypese 


stb] build2($1, $3); 
passdn_stbl2($l, $3); 


Ivisibility information 
passdn2 2($1, $3, visible types, visible names); 


‘error messages 


$$.error_msgs_s = [{$l.error_msgs_s, $3.error_msgs_ s}; 
} 
| NAME pair 
{ 
$$.xten type s = [$1.%text, "::", $2.type_s, PAIR_DELIM, $2.xten type s]J; 


stbl buildl ($2); 
passdn_stbll ($2); 


'visibility information 
passdn_2($2, visible types, visible names); 


terror messages 
passup_1($2, error_msgs); 
} 
| pair 
{ 
passup 1($1l, xten_type); 


seb lebua rad(Si) 
passdn Stb11($1); 


‘visibility information 
passdn 2($1l, visible types, visible names); 


terror messages 
passup 1($1, error_msgs); 


pair 
NAME BIND expression 
{ 
$$.xten type s = [Sl-.ttext, "2:2", S3.-xten types); 
$$.type_s = $3.xten_type s; 


Stbl build (S23); 
passdn_stb11($3); 


‘visibility information 
passdn_2($3, visible types, visible names) ; 


‘error messages 
passup 1($3, error_msgs); 
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Operator list 
operator list operator symbol 
{ 
passdn_3($1, xref_value, message_fargs, ip_mcmxref); 
passdn stbl1($1); 


$$.d_error_s = check_complex_decl ($$.ip_mcmxref_i, $2.operator_text_s, 
$$.message_fargs i, $2.line_s, $$.stbl_names i); 
!modified version of #mk_complex_decl 
$$.ip_memxref_s = ($$.d_error_s == NULL STRING) 
-> ($l.ip_memxref_s ($2.operator_text_s) == NULL STRING) 
-> {($2.operator text_s ; [$$.message_fargs i, 
XREF_DELIMITER, i2s($$.xref_value_i)])} +] 
$l.ip_memxref_s 
‘#°{(($2.operator text_s : [$1.ip_mcemxref_s 
($2.operator_text_s), 
PATTERN DELIMITER, $$.message_fargs i, 
XREF_DELIMITER, i2s($$.xref_value_i)])} +| 
Sl.ip_mcemxref_s 
‘#’ Sl.ip_memxref s; 


‘error messages 
~9HeLLOr Msqses = (951l.6érreor msqs Ss, 5>.d errors]; 


} 
| operator symbol 
{ 
$$.error msgs_s = check_complex_decl($$.ip_mcmxref_i, $l.operator text_s, 
$$.message fargs_i, $1.line_s, $$.stbl_names i); 
mk complex _decl($$.ip_memxref, $$.error_msgs_s, $l.operator text_s, 
S$.xref value i, $S.message_ fargs i); 


operator symbol 
: NOT 


Ser Opebacer Sexe se= 51 7tcext; 
S$.line_s = $1.%line; 


S$.operator text s = $1.%text; 
s9-line Ss = $51.%line; 


$$.operator text_s = $1.%text; 
v9eline Ss = 5). %line; 
} 
| IMPLIES 
{ 
S$.operator text _s = $].%text; 
$$.line_s = §1.%line; 


$5.operator text _s = $1.%text; 
$$.line_s = $1.%line; 


Vl 


LT 


$$.operator_ 


text. Ss = Bel aL 


$1.%line; 


text_s = eid 


$1.%line; 


text_s = "#"; 


$1.%line; 


Cext 7s = 51 cexc, 


$1.%line; 


text |S = 51. tcexc, 


$1.%line; 


EOxtS = 51-%Cext; 


$1.%line; 


text_s = $1.%text; 


Si s*iine. 


text s = $1.%text; 


51.%iline; 


text s = $1.%text; 


$1.%line; 


text_s = $1.%text; 


$1.%line; 


text s = $1.%text; 


$1.%line; 


$9.line_s = 
} 
GT 
{ 
$$.operator_ 
$$.line_s = 
} 
EQUALS 
{ 
$$.operator_ 
$$.line_s = 
} 
LE 
{ 
$$.operator_ 
$$.line_s = 
} 
GE 
{ 
$9.operator_ 
$$.line_s = 
} 
NE 
{ 
$$.operator_ 
$$.line_s = 
} 
NLT 
{ 
$$.operator_ 
$$.line_s = 
} 
NGT 
{ 
$$.operator_ 
$S.line_s = 
} 
NLE 
{ 
$$.operator_ 
$$-line s = 
} 
NGE 
{ 
$3.operator_ 
$$.line_s = 
} 
EQV 
{ 
$$.operator_ 
$S.line_s = 
} 
NEQV 


$$.operator_ 


$§.line_s = 


text S = S51. text; 


$1.%line; 


biz 


PLUSMARK 
{ 


$$.operator_ 
os. 11ne 7s = 
} 
MINUSMARK 
{ 
$$.operator_ 
$$.line_s = 
) 
STARMARK 
{ 
$$.operator_ 
$$.line_s = 
} 
SLASH 
{ 
$$.operator_ 
$$.line_s = 
} 
MOD 
{ 
$$.operator_ 
See liness: — 
} 
EXP 
{ 
$$.operator_ 
$$.line_s = 
} 
U 
{ 
$$.operator_ 
$s. line s = 
} 
APPEND 
{ 
$$.operator_ 
$$.line_s = 
} 
IN 
{ 
$$.operator_ 
$$.line_s = 
} 
RANGE 
{ 
$$.operator_ 
$$.line_s = 
} 
DOTMARK 
{ 
$$.operator_ 
$$.line_s = 
} 
LBRACK 


{ 


$$.operator 


Sor bine |S = 


text_s = ae pul 
Si sine. 


bext. Ss =Gi=" 3 
$1.%line; 


text s = ™*"; 


$1.%line; 


text _s = w/t. 


$1.%line; 


text _s = $1.%text; 


$1.%line; 


text_s = $1.%text; 


$1.%line; 


Eext S| — $1.%text; 


$1.%line; 


text s = $1.%text; 


$1.%line; 


text s = $1.%text; 


$1.%line; 


text_s = $1.%text; 


$1.%line; 


EOXCys >=". ", 
$1.%line; 
text _s = il Bak 


$1.%line; 


ig 


APPENDIX C - SYNTACTIC ERROR PRODUCTIONS. 


This Appendix contains the syntactic error productions that were developed for 
version 1.5 of the SPEC grammar. This version was five versions prior to the version 
used for the type checker, but the methodology used to implement the error productions 
is fully applicable to the newest version of the grammar. For the type checker to be a 
fully functional tool, these error productions must be integrated into the final product. In 


this way, syntactic and semantic errors could be identified concurrently. 


! version stamp $Header: spec.k,v 1.5 88/02/16 13:27:58 berzins Exp $ 

! In the grammar, comments go from a ™!" to the end of the line. 

! Terminal symbols are entirely upper case or enclosed in single quotes (’). 

' Nonterminal symbols are entirely lower case. 

1 Lexical character classes start with a captial letter and are enclosed in {}. 
' In a regular expression, x+ means one or more x’s, 
{ 

: 

! 

: 

! 


In a regular expression, x* means zero or more x’s. 

In a regular expression, [xyz] means x or y or z. 

In a regular expression, [*xyz] means any character except x or y or z. 
In a regular expression, [a-z} means any character between a and z. 

In a regular expression, . means any character except newline. 


! definitions of lexical classes 


tdefine Digae = (0-9) 

tdefine ligee ={Digit } + 

tcefine Letter : [a-zA-Z]} 

tdefine Alpha sU(leccter) Prades) a2) 
tdefine Blank 2 (= Venn) 

tdefine Quote oa) 

tdefine Backslash ie 

tdefine Char >([*"\\} | {Backslash} {Quote} | {Backslash} {Backslash}) 


! definitions of white space and comments 


>{Blank}+ 
[ea 7 ie 

! definitions of compound symbols and keywords 

AND :“e" 

OR See ilie 

NOT on 

IMP CLES [=a 

TEE i 

LE 2%e="N 

GE 2%>="9 

NE 2Mon 

NLT oe ae 

NGT alos a 
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NLE 
NGE 
EQV 
NEQV 


RANGE 
APPEND 
MOD 
EXP 


BIND 
ARROW 


J09) 
THEN 
ELSE 
IN 

U 


ALL 
SOME 
NUMBER 
SUM 
PRODUCT 
SET 
MAXIMUM 
MINIMUM 
UNION 
INTERSECTION 
SUCH 
BUse. IF 


AS 

CHOOSE 
CONCEPT 
DEFINITION 
DELAY 

DO 

END 

BACEP TION 
EXPORT 

Soe 
FOREACH 
FROM 
FUNCTION 
GENERATE 
HIDE 

IMP ORT 
INHERIT 
INITIALLY 
INSTANCE 
INVARIANT 
ITERATOR 
MACHINE 
MESSAGE 
MODEL 

OD 

OF 
OPERATOR 
OTHERWISE 
PERIOD 


V7) 


:{Backslash} |MOD 


Hk we 
» 


:ALL 

: SOME 

: NUMBER 

SUM 

sPRODUCT 

sSET 

:MAXIMUM 
:MINIMUM 

: UNION 

s INTERSECTION 
SUCH {Blank} *THAT 
sELSE {Blank} *IF 


:AS 

s CHOOSE 
:CONCEPT 

Tt DEFINITION 
> DELAY 

7DO 

:END 
SEXCEe TION 
: EXPORT 
Por 

: FOREACH 
>FROM 

>F UNCTION 
: GENERATE 
SHEDE 

: IMPORT 

2? INHERIT 

: INITIALLY 
> INSTANCE 
: INVARIANT 
ora OR 
:MACHINE 
>MESSAGE 

> MODEL 

:OD 

SOF 

: OPERATOR 
: OTHERWISE 
:PERIOD 


RENAME 
REPLY 

SEND 

STATE 
TEMPORAL 
TIME 

108] 
TRANSACTION 
TRANSITION 
ee 

VALUE 
VIRTUAL 
WHEN 

WHERE 


SECONDS 
MINUTES 
HOURS 
DAYS 
WEEKS 
NANOSEC 
MICROSEC 
MILLISEC 


INTEGER_LITERAL 
REAL LITERAL 
CHAR_LITERAL 
STRING LITERAL 
NAME 


! operator precedences 


! $left means 2+3+4 is (2+3)+4. 

%left os", IEF, DO, EXCEPTION, NAME, SEMI; 
&Rleft > Ge CONMAS 

&Rleft SUCH; 

&Rleft Gals 

left IMPLIES; 

$left OR; 

left AND; 

$left NOT; 

&left rg’, *>’, °=', LE, GE, NE, NLT, NGT, NLE, NGE, EQV, NEG 
$nonassoc IN, RANGE; 

left U, APPEND; 

left ee =. PLUS! MINUS: 

Rleft ee umes oe MUL aD LV, aMOD; 

&left UMINUS; 

left EXP; 

left Comey oC Gee Ss” | DOL ene Re 
left STAR; 

&% 


'attribute declarations 


&% 
{ productions of the grammar 


Start 
spec 
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> RENAME 
SREPiY 
:SEND 
:STATE 
: TEMPORAL 
= vie, 
a, 

: TRANSACTION 
: TRANSITION 
Ss gS 
: VALUE 
: VIRTUAL 
: WHEN 
> WHERE 


: SECONDS 
sMINUTES 
: HOURS 
:DAYS 

>: WEEKS 
:NANOSEC 
:MICROSEC 
:MILLISEC 


OG sie) 
SCInt) +o ene) 


ome m wen 
rs ° 


: {Quote} {Char }* {Quote} 


: {Letter} {Alpha}* 


me 


spec 
: spec module 


| spec error module 


=e 


! A production with nothing after the "|" means the empty string 
' is a legal replacement for the left hand side. 


module 
peLunct LOM 


| machine 


| type 


| definition 


{| instance ! of a generic module 


Function 
“Oper oOnal | y Virttval FUNCTION interface messages concepts END 
{ 
} 


| optionally virtual FUNCTION error messages concepts END 


{ 


} 


eptiondliysvirtual FUNCTION interface error 


{ 
} 


=e 


! Virtual modules are for inheritance only, never used directly. 


machine 
optionally virtual MACHINE interface state messages transactions temporals 
concepts END 
{ 
} 


| optionally virtual MACHINE error state messages transactions temporals concepts 
END 


optionally virtual MACHINE interface error 
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type 
: optionally virtual TYPE interface model messages transactions temporals 
concepts END 
{ 
} 


| optionally virtual TYPE error model messages transactions temporals concepts END 


{ 


} 


| optionally virtual TYPE interface error 


{ 


=e 


definition 
: DEFINITION interface concepts END 

{a 

| DEFINITION error concepts END 
{ 
} 

{| DEFINITION interface error 
{ 
} 


instance 
: optionally virtual INSTANCE parametrized_name ’=’ parametrized name hide 
renames END 
{ 
} 


| optionally virtual INSTANCE error ‘=’ parametrized name hide renames END 


{ 


} 


| optionally virtual INSTANCE parametrized name error END 


{ 


} 


| optionally virtual INSTANCE parametrized name ’=’ error END 


{ 


} 


| optionally virtual INSTANCE parametrized name '=’ parametrized name error 


{ 


we 


! For making instances or partial instantiations of generic modules, 
! and for making interface adjustments to reusable components 
! by hiding or changing some names. 
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interface 
NAME formal parameters inherits imports export 


ee 


! This part describes the static aspects of a module’s interface. 

! The dynamic aspects of the interface are described in the messages. 
' A module is generic iff it has parameters. 

! The parameters can be constrained by a WHERE clause. 

! A module can inherit the behavior of other modules. 

! A module can import concepts from other modules. 

! A module can export concepts for use by other modules. 


inherits 


inherits INHERIT parametrized name hide renames 


{ 
} 

| inherits INHERIT error 
{ 


ze 


! ancestors are generalizations or simplified views of a module 


' an actor inherits all of the behavior of its ancestors 


hide 
: HIDE name list 
{ 
) 
| 
{ } 
mHIDE error 
{ 
} 
! Useful for providing limited views of an actor. 
! Different user classes may see different views of a system. 
! Messages and concepts can be hidden. 
renames 


: renames RENAME NAME AS NAME 


{ 
} 

| renames RENAME error AS NAME 
{ 


} 


| renames RENAME NAME error NAME 
{ 


Ue, 


renames RENAME NAME AS error 
{ 


=e 


! Renaming is useful for preventing name conflicts when inheriting 
! from multiple sources, and for adapting modules for new uses. 

! The parameters, model and state components, messages, exceptions, 
! and concepts of an actor can be renamed. 


imports 
: imports IMPORT name_list FROM parametrized_name 
{ 
} 
| 
{ 
} 
| imports IMPORT error FROM parametrized _name 
{ 
} 
| imports IMPORT name_list error parametrized name 
{ 
) 
| imports IMPORT name list PROM error 
{ 
} 
EXpPOLrt 
EXPORT name_list 
{ 
} 
| 
{ 
} 
| EXPORT error 
{ 
} 
messages 
: messages message 
{ 
} 
| 
{ 
) 
message 


: MESSAGE message header operator response 


| SSAGE message header error 


ar a 
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we 


response 
response body 


| response cases 


we 


response cases 
: WHEN expression list response body response_cases 
{ 
} 
| OTHERWISE response_body 
{ 
} 
| WHEN error response_body response cases 
{ 
} 


| WHEN expression list response body error 


{ 


} 
| OTHERWISE error 


{ 


response_body 
; Opt choose opt_reply opt_sends opt transition 


{ } 


=e 


opt_choose 
reCHOOSES () tielaiiist restriction 7)" 


qs *) 
MeCHOOSE @rror field Jist restriction 


{ 


} 
mcHOUSE ’ (* error *)’ 


{ } 


| CHOOSE °{’ field list restriction error 


{ 


ee 


opt_reply 
: REPLY message header where 


GENERATE message heacer where ' used in iterators 
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opt_sends 
: sends 


a) 


oa) 


Ss 


sends 
: sends send 


| send 


send 
: SEND message_header TO parametrized _name where foreach 
{ 
} 


| SEND message header error parametrized_name where foreach 


{ 


} 


| SEND message header TO error 


{ 


Be 


opt transition 
transition 


ee 


is 


transition 
TRANSITION expression_list ! for describing state changes 
{ 
} 
| TRANSITION error 
{ 


message header 
: Optional _exception optional _ name formal_arguments 


{ 
} 


where 
WHERE expression list 
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Re 


| tprec SEMI ' must have a lower precedence than WHERE 
{ 
} 
WHERE error 
{ 


optionally virtual 


: VIRTUAL 


Be 


optional exception 


operator 


foreach 


| 


Se 


EXCEPTION 


| %prec SEMI 


: operator OPERATOR operator list 


{ 


} 
operator OPERATOR error 


{ 


; FOREACH ’(’ field list restriction ‘)' 


{ 
} 
FOREACH error 


{ 
} 


FOREACH ’ (’ error 
{ 


! FOREACH is used to describe a set of messages to be sent. 
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concepts 


concept 


where 


where 


moael 


state 


Se 


=e 


we 


concepts concept 


: CONCEPT NAME formal parameters ’:’ type spec where 
! constants 


| CONCEPT NAME formal parameters formal arguments where VALUE formal arguments 


! functions 


{ 


} 
CONCEPT 


{ 
} 
CONCEPT 
{ 
) 
CONCEPT 
{ 
} 
CONCEPT 
{ 
} 
CONCEPT 
{ 
} 


error formal parameters formal_arguments where VALUE formal _ arguments 


NAME error VALUE formal _ arguments where 


NAME error ’:’ type spec where 


NAME formal parameters ’:’ error 


NAME formal parameters formal arguments where VALUE error 


! data types have conceptual models for values 
MODEL formal_arguments invariant 


| MODEL formal arguments invariant initially 
f initially clause specifies automatic variable initialization 


{ 
} 


MODEL error invariant initially 


ea 


MODEL formal_arguments invariant error 


{ 
} 


! machines have conceptual models for states 
STATE formal _ arguments invariant initially 


{ 
} 


STATE Error invariant init rally 


vad 


STATE formal _ arguments invariant error 


{ 
} 
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=e 


invariant ! invariants are true in all states 
INVARIANT expression_list 
{ 
} 
{| INVARIANT error 
{ 
} 


Be 


initially ' initial conditions are true only at the beginning 
: INITIALLY expression list 
{ 
} 
| INITIALLY error 
{ 
} 


we 


transactions 
: transactions transaction 


transaction 
; TRANSACTION parametrized name ‘=’ action expression where 

{ 
} 

| TRANSACTION error ‘=’ action expression where 
{ 
} 

| TRANSACTION parametrized name error 
{ 
} 

| TRANSACTION parametrized name ’=’ error 
{ 
} 


' Transactions are atomic. 
! The where clause can specify timing constraints. 


action expression 
: action expression ';’ action_list tprec SEMI ! sequence 


| action list 
{ 
} 
Inaction expression 
{ 
} 


¢ ¢ 


er7ok 


° 
’ 


action list 
aee10n list action list Sprec SIAR ! parallel 
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| IF alternatives FI ! choice 


| DO alternatives OD ! repetition 
{ 
} 
| parametrized name ! a normal message 
{ 
) 
| EXCEPTION parametrized name f an exception message 


{ 
} 
{! IF error FI 
{ 
} 
| DO error OD 
{ 
} 
| EXCEPTION error 
{ 
} 
| IF alternatives error 
{ 
} 
| DO alternatives error 
{ 
} 


‘ee 


alternatives 
: alternatives OR guard action expression 


| guard action_expression 
{ 
} 
| alternatives OR error 
{ 
} 


guard 
WHEN expression ARROW 
{ 
} 
| 
{ 
} 
| WHEN error ARROW 
{ 
} 
| WHEN expression error 
{ 
} 
temporals 


: temporals temporal 
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e 
# 


temporal 


TEMPORAL NAME where response 

{ 

} 

TEMPORAL error 

{ 

} 

TEMPORAL NAME error 

{ 


! Temporal events are trigged at absolute times, 
! in terms of the local clock of the actor. 

! The "where" describes the triggering conditions 
! in terms of “TIME” end "PERIOD". 


formal parameters ! parameter values are determined at specification time 


“e 


*{’ field list '}’ where 
{ 
} 


{ 
} 


‘{’ error '}’ where 


{ 


‘{’ field list error where 
{ 
} 


formal _ arguments ' arguments are evaluated at run-time 


field list 


eet “fieidyilist *)" 


ma error «ji 


Ppiwtielaulist error 


fireldwlist. , tield 
{ 
} 
| field 
{ 
} 
fieldalist ‘,’ error 


{ } 
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ee 


field 


=e 


type_spec 


name_list 


error ’,’ field 


{ 
} 


* name list *:* type cspec 


| °$' NAME ’:' type_spec 


{ 
} 


Namen liste =" error 


*$’ error ':’ type spec 


'$’ NAME error type spec 


°S’ NAME ’:’ error 


name_list error type_spec 


eae 


parametrized name 


| TYPE actual parameters 


| FUNCTION actual parameters 


| MACHINE actual parameters 


| ITERATOR actual parameters 


: name list NAME 
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' name of a data type 


optional name 
: NAME formal parameters 


=e 


parametrized name 
: NAME actual parameters 
{ 
} 


=a 


actual parameters ! parameter values are determined at specification time 
re eo CG. t St 
{ 
) 


&prec SEMI ! must have a lower precedence than ’” {’ 


mot error “ )}” 


{ 


fel abo li sc error 


if -3) 


=e 


actual arguments ! arguments are evaluated at run-time 
“(arg lisceaje 
{ 
) 


| &prec SEMI ! must have a lower precedence than ’% (’ 


feo errors.) " 


im ( “arg list error 


=a 


ara list 
ssarag list *,’ arg &prec COMMA 
{ 
} 
leanc 
{ 
) 
IearG list: *," error 
{ 
} 
arg 
expression 
{ 
} 
| pair 
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me 


expression list 


: expression list ’, 


| expression 
{ 
} 


| expression_list 


{ 
} 
| error...” 


LO) 


ea 


expression 
: quantifier 


‘,’ expression 


1 Werroer 


expression 


ae 


prec COMMA 


| parametrized name actual arguments 


field list restriction BIND expression ‘)’ 


| parametrized name '@’ parametrized name actual_arguments 


| NOT expression 


| expression 


| expression 


| expression 


| expression 


| expression 


| expression 


| expression 


| expression 


AND expression 


OR expression 


IMPLIES expression 


DEE 


expression 


expression 


‘>’ expression 


i] 


expression 


LE expression 


&prec 


prec 


prec 


prec 


prec 


prec 


prec 


tprec 


$prec 
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NOT 


AND 


OR 


IMPLIES 


LEE 


LE 


LE 


LE 


LE 


expression 


expression 


expression 


expression 


expression 


expression 


expression 


expression 


’ , 


GE expression 


NE expression 


NLT 


NGT 


NLE 


NGE 


EQV 


NEQV expression 


-’ expression 


expression 


expression 


expression 


expression 


expression 


expression 


expression 


MOD 


EXE 


expression 


expression 


expression 


expression 


expression 


expression 


expression 


expression 


expression 


expression 


expression 


U expression 


1 


&prec 


&prec 


&prec 


&prec 


&prec 


prec 


&prec 


&prec 


&prec 


&%prec 


&prec 


$prec 


&prec 


&prec 


&prec 


&prec 


LE 


LE 


LE 


1G)3, 


LE 


LE 


LE 


UMINUS 


PLUS 


MINUS 


MUL 


DIV 


MOD 


EXP 


| expression APPEND expression &%prec APPEND 


| expression IN expression %prec IN 


| *'** expression prec STAR 
! *y dis the value of x before a transition 
' xy is the value after the transition 


| ’$’ expression &%prec DOT 
! $x represents a collection of items rather than just one 
sl = {x, $s2} means sl = union({x}, s2) 
' sl = [x, $s2}] means sl = append([x], s2) 
| expression RANGE expression prec RANGE 
x in {a .. BD) iff x “in (a2. bi} ei ft a <—ix <= 5 
! [a .. b] is sorted in increasing order 
| expression ’.’ NAME &prec DOT 
| expression ’[’ expression ’]’ prec DOT 


| *C - expression: ’)”’ 


| ’(' expression units ’)’ ! timing expression 
geese sis. ' The current local time, used in temporal events 

| DELAY ! The time between the triggering event and the response 

{ PERIOD ! The time between successive events of this type 

| literal 

| literal ’@’ parametrized_name ! literal with explicit type 
Bae ! An undefined value to be specified later 


eae ! An undefined and illegal value 


| IF expression THEN expression middle cases ELSE expression FI 
{ 
} 


| expression ’>’ error 


i) 


| error ‘<’ expression 
{ } 

| quantifier ’(’ error ‘)’ 
} 


| quantifier error 


{ 
} 
Ipquancicier '(" frela Vist restriction BIND error *)” 
{ 
} 


| parametrized name ’'@’ error 


| NOT error 


| *’=" error 


*’ error 


S$’ error 


(’ error ’)’ 


— 


Welt serror IHEN expression middle cases ELSE expression: F1 


mir expression THEN error middle cases ELSE expression Fi 
oo) 
iNiE expression THEN expression middle cases ELSE error 
{ 
} 
eo lveralo® 6" “error 
{ 
} 
| ’(’ expression units error 
{ 
} 


middle cases 
middle cases ELSE IF expression THEN expression 
{ 
} 


{ 
} 


middle cases EVSe Tr error 
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{ 
} 


| middle cases ELSE IF expression THEN error 


{ 
} 


quantifier 


restriction 


} 


SOME 


NUMBER 


SUM 


PRODUCT 


SET 


MAXIMUM 


MINIMUM 


UNION 


INTERSECTION 


SUCH expression 


{! SUCH error 


{ 
} 
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literal 


expressions 


INTEGER_LITERAL 


REAL LITERAL 


CHAR LITERAL 


STRING LITERAL 


’#’ NAME 


‘([’ expressions '])’ 


! enumeration type literal 


! sequence literal 


expressions ’ }’ ' set literal 


expression ';’ expressions ‘%}’ ' map literal 


Mies pan hws? 7] 


! tuple literal 


bain” }* 7 one ol diteral 


CE ror 


error.’ }* 


error oi)" 


e ? 


expression ’;’ error ‘'}’ 


Paar eiist error 


expression list Error 


' relation literals are sets of tuples 


expression 1i75¢ 
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padi ast 


pair 


units 


so parm slist ©) epaie 


| NAME pair 


apa 
{ 
} 
Pale gbista | -C€rooc 
{ 
} 


NAME BIND expression 
{ 


} 
NAME BIND error 


{ 
} 


NANOSEC 


jf eMICROSEC 


i) MILLISEC 


| SECONDS 


(PeMINUTES 


| HOURS 


| WEEKS 
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s 
Operator list 
Operator list operator symbol 
{ 


} 
| operator symbol 


{ 
} 


| Operator list error operator symbol 
{ 
} 


operator symbol 
NOT 
{ 


} 
| AND 


[ IMPLIES 


ere a. 
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Pi pent 


| NGT 


| NLE 


| NGE 


| EQV 


NEQV 


| MOD 


| EXP 


| APPEND 


| RANGE 


198 


19? 





APPENDIX D - TYPE CHECKER ATTRIBUTES. 


This Appendix contains a list of all of the attribute descriptive names used in the 


implementation of the type checker with their purpose. This list is not all encompassing. 


Various attributes that are slight variations of the below named attributes have been left 


out. All of the attributes not included have an "ip" prefix with a "main" name 


corresponding to a name listed below. 


Attribute Name 


% line 


Jotext 


actual_name_text 
actual_params 
actual_text_s 

arg text 
arglist_text 


args 1 


d_error_s 


env_1 


error_msgs 


Attnbute Purpose 


A Kodiyak predefined attribute yielding the line number 
in the source text of a terminal symbol. 


A Kodiyak predefined attribute yielding the actual text 
of a terminal symbol. 


The actual text of an actual name. 

The actual parameters associated with an actual name. 
The actual text associated with a non-terminal. 

The text of an arg non-terminal. 

The text of an argument list (arg_list) non-terminal. 


The arguments associated with a particular non- 
terminal. This attribute is commonly used in the formal 
name non-terminal to obtain the arguments associated 
with the name so a "pattern" may be created. 


An attribute containing an error message relating to the 
declaration of a new name (if any such error exists). 


The current environment of a non-terminal. 


This attribute contains all error messages identified in 
the current and children non-terminals. 
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fieldpattern 


global_type 


ip_lclzd_mcmxref 


ip_mcmxref 


ip_mxref 


local_types_s 
line 
message_name_s 
message_fargs_s 


mod_types 


module_name 
mxref_value 
name_fargs 
name_text 
name_type_text 


name_type_value 


The string containing the non-terminals name and it’s 
type, separated by a predefined delimiter. 


A map containing all global type names and their 
translation. 


A localized attribute containing the same information as 
the mcmxref attribute. Used in the final stages of layer 
2 to integrate 1p_mcmxref attributes from different 
modules. 

A map containing all module, message and concept 
names. This map is used in layer 2 to build the layer 3 
attribute "stbl". The range of the map contains patterns. 


A map which is being constructed to contain all module 
names. The range of the map contains the module 
names pattern and cross reference. This map is used in 
layer 1 to obtain information needed in the layer 2 table 
eipoinemxref 

The type names that are local to a non-terminal. 

The line number associated with a non-terminal. 

The text of a message’s name. 


The text of the formal arguments of a message. 


A localized map containing the type names and their 
translations that are visible. This table and the 
“global_type" attributes are used to build the 
“visible_types" map. 


The name of the current module. 

The cross reference value of the current module. 
The formal arguments associated with a name. 
The text associated with a formal or actual name. 
The text of a name’s type. 


The translated value (obtained from the visible types 
table) of a name’s type. 
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name_params 
operator_text 
signature 


stbl_class 


stbl_names 


stbl_params 


stbl_result 


text 
type_name_text 
type_name_value 


type_table_i 


visible_names 
visible_types 
xref value 


xten_type_ 


The parameters associated with a formal or actual name. 
The text associated with an operator non-terminal. 
The signature (name and arguments) of a non-terminal. 


Classes of all names used (e.g. Function, Message, etc.) 
Accessed by the cross reference value of the name. 


All names used throughout the program. Accessed by a 
cross reference value. 


The formal parameters of a name (if any). Accessed by 
a cross reference value. 


The resultant type of aname. Contains extended type 
information. Accessed by the cross reference value of 
the name. 

The text of a non-terminal. 

The text of a type_spec’s name. 


The translated value of a type_spec. 


A map coalescing the contents of the "mod_types" and 
“global_type” tables. 


A map containing all names visible. 
A map containing all type names visible. 
The cross reference value of the current name. 


The extended type of a non-terminal. 


202 


REFERENCES. 


1. Berzins, V., and Lugi, Draft of Software Engineering with Abstractions: An 
Integrated Approach to Software Development with Ada. Addison-Wesley, 1988. . 


2. Weigand, J. Design and Implementation of a Pretty Printer for the Functional 
Specification Language SPEC, M.S. Thesis, Naval Postgraduate School, June, 1988. 


3. Berzins, V., and Gray, M., "Analysis and Design in MSG.84: Formalizing Functional 
Specifications," JEEE Transactions in Software Engineering, v. 11, pp. 657-670, 
August 1985. 


4. Johnson, S., YACC--Yet Another Compiler Compiler, Bell Laboratories, Murray Hill, 
NJ, July 1978. 


5. Farrow, R. "Generating a Production Compiler for an Attribute Grammar," 
IEEE Software, v. 1, pp. 77-93, October 1984. 


6. Herndon, R. Attribute Grammar Systems for Prototyping Translators and 
Languages. Ph. D. Dissertation, University of Minnesota, 1988. 


7. Nicholas, C. Assusring Accessibility of Complex Software Systems. Ph. D. 
Dissertation, University of Ohio State, 1988. 


8. Aho, A. and Ullman, J., Principles of Compiler Design, p. 58, Addison-Wesley, 
1979, 


9. Knuth, D. "On the Translation of Languages from Left to Right," /nformation and 
Control, v. 8, pp. 607-639, 1965. 


10. Brooks, F. "The Mythical Man-Month," Datamation, v. 20, No. 12, pp. 44-52, 
December 1974. 


11. Verner, J and Tate, G., "Estimating Size and Effort in Fourth-Generation 
Development", JEEE Software, pp. 15-22, July 1988. 


12. Penello, T. "Very Fast LR Parsing," Conference Record of the 9th Annual ACM 
Symposium on Principles of Programming Languages, pp. 224-233, 1982. 


13. University of Helsinki Technical Report A-1978-2, The Compiler Writing System 
HLP, by K. Raiha, M. Saarinen, E. Soisalon-Soininen, and M. Tienari, March 1978. 


14. Lorho, B. "Semantic Attnbute Processing in the System Delta," Lecture Notes in 
Computer Science, v. 47, pp. 21-40, Springer-Verlag, 1977. 


203 


15. Ganzinger, H., Ripken, K., and Wilhelm, R., "Automatic Generation of Multipass 
Compilers," /nformation Processing 77, Proceedings of IFIP Congress 77, pp. 535- 
540, North-Holland Publishing Co., 1977. 


16. Milton, D., Kirchhoff, L., and Rowland, B., “An ALL(1) Compiler Generator," 
Proceedings of the SIGPLAN '79 Symposium on Compiler Construction, ACM 
SIGPLAN Notices, v. 14, No. 8, pp. 152-157, August 1979. 


17. Kastens, U., Hutt, B., and Zimmerman, E., "GAG: A Practical Compiler Generator”, 
Lecture Notes in Computer Science, v. 141, Springer-Verlag, 1982. 


18. Bell Laboratories Computer Science Technical Report 39, Lex - A Lexical Analyzer 
Generator, by M. Lesk and E. Schmidt, October 1975. 


19. Naval Postgraduate School Technical Report NPS52-89-029, A Student's Guide to 
SPEC, by V. Berzins and R. Kopas, May 1989. 


20. Naval Postgraduate School Technical Report NPS52-87-032, The Semantics of 
Inheritance in Spec, by V. Berzins and Lugqi, July 1987. 


21. Beebe, D. The Design and Implementation of a Syntax Directed Editor for the 
Specification Language Spec, M.S. Thesis, Naval Postgraduate School, June, 1989. 


204 


BIBLIOGRAPHY. 


Adorni, G., Boccolatte, A., and Di Manzo, M., "Top-Down Semantic Analysis", 
Computer Journal, v.27, August 1984. 


Berzins, V., Gray, M., and Naumann, D., "Abstraction Based Software Development”, 
Communications of the ACM, v. 29 No. 5, pp. 402-415, May 1986. 


Booch, G., Software Engineering with Ada, 2nd edition, Benjamin/Cummings, 1987. 


Cleaveland, Craig. "Building Application Generators," JEEE Software, v. 14 
pp. 25-33, July 1988. 


Farrow, R., "Generating a Production Compiler for an Attribute Grammar," JEEE 
Software, v. 1, October 1984, pp. 77-93. 


Fisher, A., CASE, Using Software Development Tools, John Wiley & Sons, Inc., 1988. 


Herndon, R. and Berzins, V., "The Realizable Benefits of a Language Prototyping 
Language", JEEE Transaction on Software Engineering, v. 14, June 1988, pp. 803-809. 


MacLennan, B., Principles of Programming Languages: Design, Evaluation, and 
Implementation, 2nd edition, Holt, Rinehart & Winston, 1987. 


Naval Postgraduate School Technical Report NPS52-87-033, Specifying Large Software 
Systems in Spec, by V. Berzins and Luqi, July 1987. 


Naval Postgraduate School Technical Report NPS52-88-007, Generating a Language 
Translator based on an Attribute Grammar Tool, by LuQi and R. Herndon, April 1988. 


Naval Postgraduate School Technical Report NPS52-88-038, Languages for 
Specification, Design and Prototyping, by V. Berzins and LuQi, September 1988. 


Reps, Charles. Generating Language-Based Environments. Ph. D. Dissertation, 
University of Massachusetts, Amherst, 1983. 


University of Minnesota Computer Science Department Report Technical Report 85-25, 
AG: A Useful Attribute Grammar Translator Generator, by R. Herndon and V. Berzins, 
July 1985. 


205 


University of Minnesota Computer Science Technical Report 85-37, The Incomplete AG 
User’s Guide and Reference Manual, by R. Herndon, October 1985. 


206 


INITIAL DISTRIBUTION LIST. 


Ada Joint Program Office 
OUSDRE (R&AT) 

The Pentagon 
Washington, D.C. 20301 


Commanding Officer 

Naval Research Laboratory 
Code 5150 

Attn. Dr. Elizabeth Wald 
Washington, D.C. 20375-5000 


Defense Advanced Research Projects Agency (DARPA) 
Integrated Strategic Technology Office (ISTO) 

Attn. Dr. Jacob Schwartz 

1400 Wilson Boulevard 

Arlington, Virginia 22209-2308 


Defense Advanced Research Projects Agency (DARPA) 
Integrated Strategic Technology Office (ISTO) 

Attn. Dr. Squires 

1400 Wilson Boulevard 

Arlington, Virginia 22209-2308 


Defense Advanced Research Projects Agency (DARPA) 
Director, Naval Technology Office 

1400 Wilson Boulevard 

Arlington, Virginia 22209-2308 


Defense Advanced Research Projects Agency (DARPA) 
Director, Tactical Technology Office 

1400 Wilson Boulevard 

Arlington, Virginia 22209-2308 


Defense Technical Information Center 
Cameron Station 
Alexandria, Virginia 22304-6145 


Dr. Amiram Yehudai 

Tel Aviv University 

School of Mathematical Sciences 
Department of Computer Science 
Tel Aviv, Israel 69978 


207 


10. 


ie 


12 


13: 


14. 


ay 


16. 


17. 


Dudley Knox Library 

Code 0142 

Naval Postgraduate School 
Monterey, California 93943-5002 


Fleet Combat Direction Systems Support Agency 
Attn. Mike Reiley, Code 00T 
San Diego, California 92147-5081 


Fleet Combat Direction Systems Support Agency 
Attn. George Roberson, Code 8D 
San Diego, California 92147-5081 


International Software Systems Inc. 
12710 Research Boulevard, Suite 301 
Attn. Dr. R. T. Yeh 

Austin, Texas 78759 


Kestrel Institute 

Attn. Dr. C. Green 

1801 Page Mill Road 

Palo Alto, California 94304 


Lt. Robert Kopas 

Department Head School Class 110 
Surface Warfare Officers School Command 
Newport, Rhode Island 02841-5012 


Massachusetts Institute of Technology 

Department of Electrical Engineering and Computer Science 
545 Tech Square 

Attn. Dr. B. Liskov 

Cambridge, Massachusetts 02139 


Massachusetts Institute of Technology 

Department of Electrical Engineering and Computer Science 
545 Tech Square 

Attn. Dr. J. Guttag 

Cambridge, Massachusetts 02139 


MCC AI Laboratory 

Attn. Dr. Michael Gray 

3500 West Balcones Center Drive 
Austin, Texas 78759 


Office of Naval Research 

Computer Science Division, Code 1133 
Attn. Dr. R. Wachter 

800 N. Quincy Street 

Arlington, Virginia 22217-5000 


208 


1, 


20. 


AN 


Ze. 


ce: 


24. 


25. 


Office of the Secretary of Defense 
R & AT/S & CT, RM 3E114 
STARS Program Office 
Washington, D.C. 20301 


Oregon Graduate Center 
Portland (Beaverton) 
Attn. Dr. R. Kieburtz 
Portland, Oregon 97005 


Software Group, MCC 
9430 Research Boulevard 
Attn. Dr. L. Belady 
Austin, Texas 78759 


University of Pittsburgh 
Department of Computer Science 
Attn. Dr. Alfs Berztiss 
Pittsburgh, Pennsylvania 15260 


Purdue University 
Department of Computer Science 
West Lafayette, Indiana 47906 


The Ohio State University 

Department of Computer and Information Science 
Attn. Dr. Charles Nicholas 

2036 Neil Ave Mall 

Columbus, Ohio 43210-1277 


Berzins 

Code 52Bz 

Computer Science Department 
Naval Postgraduate School 
Monterey, CA 93943-5100 


209 











DUDLEY KOK LIBRARY ™ 
NAVAL PO3YGRADUATE SCHOOL ~ 
MOI FLALY, CALITORNIA 93943-6008 




















































































. ave - ” 
e ad = 
P . - . 
. - «e<- 
. a - 
° = — - oe - - 
a - . 2 ow i. e 
° “ o 
- - a Ee = 
e r . Pa re - = 
« . . a - - ~ ane ™ - 7“ . 
Sd bad an 2 = = e - - - = 4 
ra om = . a - e - -—« “" © e bd 
2 = ba - e “~~ _ - - = 
= -—_ ° - - = - - =e as 
° e a =" ad - “e - w = 
Par = - =, « - er oe F- a 2 & we e 
. - - d = - "“"“— ae ad - 
° . - ~ ow ee 
: . ’ -- = owe © «6 ~~ « 
ad - - = . - - 7. - - ‘ ad ae 
. - © Te v~ - 
a * . - « ww - ae ee om 20 
. bs 2 . ° © oo - - - = 
= ad e e * - - - ro = y= mw 
2 = - ‘ - we wevee oe = 
i . < ~ ° - - ” pate «3 id “« oe ee. w- 
= > wn SS “. a owe ~ ot oe —-, Pe 
3 . wees eo O © - ew. ° Pe oe ee oe 
. ps * o ere ee - - we oc 
ha = = S ® - : ° A - © “- er a Cn fee ow lw - = + owe mee 
rach ~ - e bad sd i . - a 2 . . | ° = ie is = oe = - « me - -_ 
= J ¢ ° - é .? M hed wie . rem oa, ’ . ae se - ” Sie 
4 « po s o «- * id a = ” - - 
= * A . be ° . - - P Seas al eee 2 ehete~e™ © Fear wwe = = eo OO at ew a e« 
+: = baad . ” . - . “= ee ee ad Sg ae ow 2 @ oF “ge 
ia = . - = - ~ oem a - “so 3 2168 ee ee wer on 
> e* ° : * ms : 3 - - td bs va o « ea wees . “- <w~- ~ - ewes ~ 
” ° ° ° ° - a = - i« - = eer es wit ae beatctad wh .Sy2 o - - oe 
te o * ea . one od ad "— “cee - “me = an = —or eye 
° : ’ - e« ¢ « ¢ - = - - . woe ee oon gt ate ee . -, ~ 
~ o . a ° ¢ Py . . * ° Ca ah al * — as “er FN - 7" 2-8 © fees 
- - o - are ~ = ’ "ae =e —wme == ~~ —_— PY = 
= ~~ * e 2 ie eS - . = « ‘ - -# = e oss 1 # wv * @ . cm we © a 
. ; 4 : E e - 7 P « > « . vw owe - et oem ce «9M e oF08 « aoe © oy 
<i - - . ate . o- ie = ~ “6 =o = eo fratern os o.2 8” Orne ty oe ~~ nen we ° -. fe eS MK ee ee 
- aie = - oe “+ - - ver wre -~v @ SFO BT ae OGD 6 COS RD ee Oe i hg i 
- ~ e ted bal “6 = a ay ° e- ao —— ae te ed « wore e meme we PRES = 
- ~ aoe * ° ° ¢ wee 7 = : = 080 to me emaw aan 
-. 77> me = e - *, e «* : 4 . - “. OF et ed ~ 7 = 08 ——— @ = " -e - - eo m oem y i gal 
>" : =f ma = a = 5 7 we . eae nf LC oth oouw i belafiel 3 oaem eet eer Home ON ate et fag & ew 
~ - . a e ¢ : ° - ® - - ow + wre = ef amin s ee ee — 
= — dis - = ° - x - ° - a an “" ee oe | te ee swe ee 
o\0% Ds id o = ° © - = mo ° “sc vee - Oot Te OP ewe ae et ot ew rh oe 
= on , ~ f ° = 2 . 7 . “e ow ° -".°a “ee we o wet er a n0e ~ 
x r + e « . ’ ’ = - ere OF Swen: om we 9 eG Ge ate? = Oe eee Ete > mm, « 
: > ‘ os « opt ndash CP oe rret er OF mm tamy as * OPS Rtg ween. ue mm oe 
- - - * id a oer ew Oe = nto Me «Ca veges ST @ gt St ee “ee ee ed - ~« 
zn : : : 4 5 = = ein ff ome « evar wwe 6e a ee ae OO eg Ce YS TU we 
° ic id - = P 6 - - rm Op =a oft Oo Vac mey See Orme F Sahl te POT oe 
ae ~ pee . . . = i pate, _ a pare »o oe -2@ Set ee ee me werware are onal ae etngt img 
A ee ~ Boe a : = oT A ae. egreeere « ee ee ee ae ee =~ me 
a es = “0 oe - vas » a © . * set a =e e- - s¢ - ad v=-—- «# on aP Oe ares fe O9e & on ge Ry Ce ww ow 
=e s s ~ : e . 2 my - é - oe ayie?  #.8e8 Oe ee Fg ee, EL ee ge atm (DS Oo Ren ge 
= = eceueee = « . é; i + > a us ¢ ~ ~~ = ot = # Wee © ogee Oe Fp One oe" we wy eet cet Pe Phe eon. 
a a ~ ‘< ’ od . ee = - 7 z ve FOS CR el Se FO BGG Be Or, ye Oe ov Gere mer moe 
> penn Ore = Ee = : ~ ° ‘ =e _ - -"* ~ “iw "a © we ined ve a ew oe ee te ee 
r= ee > . ™ ° . . “ zs z = _ wm rere . ws see weorwr a = oP te O89 ow ering mw A Catia, Tey SO Merle o oue 
." ety mM" © ~—- . e <. s . ° - E > F - = ne fe a ae - @ -9< dot wg ee = “we Stet on od. (RAO gate Sagging dirs sya ushy 
~ ~ ne Ee e v= ? ° . =i ad me o* d= 5 Pree oe ee ee ee ee) Pel CE. er. Ste? nt a rer 
ae Lag 2 bed aps ~ « ° = - x . x ° ee te se ft odyre eo we ete y ew fate ee ee © te 
% © = - om . “t 4 ie we * ¢ ~'% "re *° e aly = 6 Bek ee OOS Se syle OE erage? Ma Rie = wee © 
ne =m * en 2 = . : ~ - 7 = “; a = «“ ~ee wt ete ewes? oP ur dated Cento DOP OD Oe OL Dt mend ew 
° .~ a = ° : ° ; nigh ‘ i 4 ee = 4 f owe ° « Peet 8 ore Ae FF Ue 4: wgere Fo Ore ean Og a 8 Fe te ee he 
oe > ~ ~ , - ¢ = - o « owt gfe Po wee 5 . CO gt of deel eum Py of wae ou. Wee" © ee en OSI ow Fee et gm as 
a “4 om Pete’ 3 lag * , ° . ’ ahah ae . . Sachs me ae ele Arete ee Oe GO OER Bay gOS MOCO EOE E NO we ei web writen ots? Alen 
= —: ee: ¥ .- : < : « “ . ooh sige pee oe ale? eet ee ee ee Ont OP ent FA ae a" Ee FE Eo nae Oat ome me ema oe pees 
° mse" - x = . > wee . F 4 " bs am an o =9c.0e a Mac ~ a Pe 2 ee Fe eer ® Mae Pee ee Fad et ome EOC OA EE aatg crt a gs ee 
bea ee sa > « . ~s >< = . ~ 3 ‘ ia ieee 5 wen De ei - ° o . a a OF te me ae ee & TK ale ie EEE OO we FOOT Ge et Cae aed apt fe pst 
ow. da, OOK & — id = : s = . > a ame ” ~ @ 2 R wise e . 9 pe OO Ee eae | ge ent. De Go Oe sae COE Fag Pass ORL ow grey CT ey, Pin whem P 
a an Oe, Sty . dae RR +2® -* F - fas a 0 aor om 2 ae ae et at rare MOR ER MT © caege ge ge at FIN TIP Ae CE i ge Ee 
nage aie weaer? - 4 pase $ w - a. . — P ‘ . va08 =e a 9 ‘3 ote Pema et R Ee OI eae EE = 8 6 ZENE BW OO Re aw te OS sar Oa ote ge oe. woh cee oe 
an ener = e.! . 2 on - a eS Ben . 108 ee e - a» Pt ee A ee eae 58 ot el 8 FF mem ye tie AG i aD eB, Men 
me Oe . =o nue © oe ~e - . . 0 mat 2 e ee — sere FP aPC Cae te Met Oe te Les wl ray rete OP OO Ete EO gee gh PR aly ge DOW ung Rath gs Tagine > 
© wm Ts % ME we = 7 Py elie 0 - ° 7% “we. ots . * ¢ - - * ‘ > E- z ° Vaart? vette « Oo OE 0? 9 AE OEE Be ote OP TLE PE BOG m, PaO Oe lee. ag pap at Opt neg 
awe we s- 1 ~~ ai a — os : * ‘ < 4 ee os = "ae , ~ : « poe o Pt ~ PR 8 FO OO Ree at BF ER Cee MY On OO BE Ca GO sete Te ween sy) atest pene ol eins 55 Age Rrsanee: 
nae = a “= me = “uP . 1 ~ . a beg ee © P, e =eew owe Fy og POR ot FH et oe» OOF ED OP OE BG he ELE PEP Ral MG BOOT TER gD 1 Sh BO age 
~ >. ~~ Sia " , . . , y’ « . te ie i le eee Ks " eo Met eee eT Pee 4 at Pat tou 2 ee eet capers ge Dt or phe eee ey OF OM Ope ft He Ores Fae, Mae mn yp 
wt ~ ‘ ota? ove Melo * -- 2 "ms OS oem OP oP ote weve oh COE at OS OKO GE EGE LIPO OM EE gO Oi gaR SE Eat A RPE aR, a Oe oe ae 
. © . . 4 i eu ow Syn wes o yh. Odeo =e sue" ne ee |e OO dae Ply Lewy Oe SF gh UE He IE Cyt IS eee ohh OU ewote eqs 
. . ni Fifa ‘ ° Pa P 600 - Rint i ged ad ew et 0 oe A AO Oe Oe COL Oe EES i gD APOE BOO ED GP AE EE og A GN in A ope 
bio ~ a " ‘ * = oe ‘ ae eee we ‘ or Pare ree tet gta wt = pt GO t8 seg tere Po ®; WET PEP FRE Ren! CORR ag ae FE ILA Lite Ae Eek OF EP pote ee + 
> = as by = 4 = a » Pe ee Mt a be MOT Mw? Be PEEL PAE OF EM AAA PE GEE AOR ph BLOT See Oe grapes FP gre 
~*~, “e . “f ™e e ee : a ag = 1‘ op preeny . ow ee COON. ty OP wes a Age LEE Cow PEE Mag St i OIE ee Oe AO Ge LD me 
ry oot A a % . . ‘ ‘ « , « : E i ee wi ores ro ee Pee 08 ORD OP Pe Mette IR © +E SR Em Fee OR ET Cree re? oe Ee iP ee Ree eee ee 
— a sd i. . re “ : . * id = aa a * ognee ave 4 Pee ga OD te OE O le OO al GUA ME AOL n Al CENT HOES Om OD et ees OD oe OS wee tA Fiat, aN “OO On Bee, weer Re heer , 
a . i = = - Sper - Od * am ne ne we” ° * we ee 6 ge Ome we mo =~ Fe 8 OEE we gem Ge Bie LAO PONG ORD Fi @ ERO ha Ne, feo I ae ma glh Pape 0 
——————— ae to P *  peren oa » ee” EF eFC Ee ge Prtet y= et Rye TAP? OER M 6s Diet eat Beer 8 oe ig ae ge Fae gm ge at yl, 
—= = ~e a Py . bs oe we we OG A EE Ot CO Ge GB AIS TLV OGD BS A CATE BO og EOD e AL eg UTE Py Tete gh 
— > ates & “ — 2 me «% - 7 so ,-007 - @ 4 - - a Ne ete CF OO TY BEN © ogee BOO F OOP SE PN Oe oi ne eC CRO PM OES nO B= OE AO ah ie AD MA ge a, 
= —_—— we : po i‘ . 2 ‘ 2 : st ¥ fg = 5 Pe ae OMe ot oe ‘ ? pveP ees 2 OF AF RED fe BOLO Feet FEAL y AOR eR YOM oe hE OE eh MUM Oe OE yl ag gt pale Oe ee oe 2 
—— (ae . - et \ ; : ’ - , ” ge 2 das ee ee {Oue» o- cowewn ora 8 NOT AO oA TEER OO eT ate FST Rhee rigepwer atte Cyne Es was Ope so” mi dal UNA © papraan 
————— <C ove" “= : s Pa; ‘ ee, een Lag a al ye ¢ rs o 2% ele oe CERF BOT gh TT OS A FOT De ONTO LOK. gm 8° AE MEH ae res Lat pag rAd O° Matis Poy et BP e aagerge EEE One Pm 
SS ed . wil ° . . pf ar “ — 1° Ba teem mer we PEt Ree EAS! ORE e BO et PCr aw: FX FUER Ae Ce oat © Ge 6 ae OO FO EO age a EGE GO PA OE oe Oo 
= ——— (ac ~ ‘ 4 re oe 7 re ode A OO AEE LE ONE AGI O RG FB LEONE BO RGA ETO, Lig AP OR IOy OL GLP Er OO NIP: iE gle oY gE AARP OE pice Clee 
——— ——7 bs pets p 7 - == ae es oi » ; Fatwa © we POE eS EEE OF epee © Bh 70 OVEN TNO Fe bgt FAT Say] Mes PE Oe gE ST ee st gh Peo Pe exe Pili &. Oe tO Oy 
——eE cm . - _™ “ ’ - . ’ Pa) ¢ . » . f sae a? PN atten OMe Fe 8 OF AES Ogg hae ON eM RF Bg IAT re PY POE STR VEE! Re OE eb Te 2 Re EE Ged? ot Fin ERO BOOS ype © aig net wea 9% 
—_——————— reve i: = te "t Fy * ores ot a . ws a ee =f < . -~- ote Ne gem ler FF oO WP ere FO: TGP G8 O89 OUT IT? HOw LEY Y ow J ONT BOF Fe HEN ORIG e OP ies a ee CEP kp EOS wt Fo TO om teeny 
——_——————s ste A . . Tr “* n e ‘* Fer ~ P “a o ce Fite we FR CO VLR EE LET IE PTF RE OV ge PE DAE OL LE EP PD F0 B PAP OL ag SOR DE A OE non 
_—— —! . - ae ee ? s my oa P . * are y cate + wwe tet Ce ae OO 08 et ss ly 1 SPW MH FTE DEED ee BE LR AP RO PD GE gg BOE BOM Ba gts ean gt 8 LE A ae, 
sd ~~ ne “el A . att . . = — e: ¢ : = ow opr pee UP srr o> We G8 ACID fo ONE, OEM Lott are a om oe ON OPS Oe RT De rte CORF €t rtp ir 1 ee gt OB ot ob Cera mt rey et 
— ——— < ~ tate ditattlind es >> . e a ‘ ee eata o® Pa a a of 1 ee? abe whet or) wie ede AE PORE EO oh oe oP Be ph GRP Estes D ge gh gt ow OER Ee ee Fe Od ee See 
a 2 ~ Pa ae . < = ¢ ' > gt ened es he SES Coe ee yee LOL NO BOLL a PAO! OES F GO 6) AAT MOE oP. Pad Hoe Ay tae PRG” He WG? AEE. we gigs piper gm ants Me Mewes TP 
oS SSS '@) Bry os Md bel = * id af one SO zeae esr 4 -— Nog 2 Sp EES me ERE OMe Me te A ON AOE gk EE Mtg wae Oi PEE RD EE et ie HD OTF Oy EN, OO ig emer, My 
—— 4 wes as « . bal - - = ws . OP OO OE BP Oe EE. FOE PA, OEE Bg FO FFE OO OP eG, Aah GO £18) ig hr Te OOF FP eRe oe Te Og gp 
———$_—— -* ro eae VO rg bd met as - A se f . e P 2 at YY RO ee CORE PN TIT eet ec! OO whee ee, reat RHF OG Oa FT Ag Ot eet OPER gee S WT we Me hie P Tat aay 
— —___—_— ii ~ eve <« ‘yo 5 - S w We OF eh LOT BF IP 8 ge FELL AF PB OO SC AP EPG Oe we G OL ITP OOY GREE A et O OT A ig iW gr Ot FSS, RAB BO pra 
—= a x eo igs . “k » . a ae * = i _ 7 me, eeoet Grate OP Be gg Me 8 Ee Ale RE FLED Ge BERT OMG 9 OLE LOE Te Pg BFA $TUOe merge? Eres = Cb Farge 
—_—_——— ~* eos - * 2 * uo are * i « F 5 P a o eo = > — < ip ag EN gar ae a ae 8 OM Fok OE BUT ct rte UE Let Beh GE OF” Ft OTS! BO iy FM asta gta” to Beate 
oo > . "a = ple ate ark ey ¥ =] e we é 4 - P De CA Mt a Rap OF One AO TE FE Mol OF OF af Cp PSs OE A Gh BAGEL TP AD, Fy ROLE a EES F0 Be oe © ge PE oh Ot A RAO gm, apie 
SS" a a nae =i . . w ¢ ayaa? og 4. OP whe AE OO waa Fe Gt oh a CARINE an 8 OREM ETIE BOR Fe ENO At LEE BINT ORO RR eee nee emg a OF te pleat g 
_ { ] J wd . reg a ‘ = ~ ~ = F ra e ’ . ugk ot op @ ew? ee ee ee) ee ee el ae a ET le ed ad 
———SSS J “~ uy = e . re ovr yes y ow oe 1 pre PET @ en € EP OC MOE EE FE a pi OH AF OE ER SLAM GED Ca NT OOOE 18s SNE Le Opty mine al ST ee 
———— en wh ¥ ‘<i a nll . = a P ¥ ws o*° f hd ee e gk etee eer 5 7 Pe ee eee et ee a ed ee a ee 
—_—_—— OQ we avean a Lond - co ana “ < ~ ‘ r ¢ , Ace gale reals ooeae'ge, is So GAVE OG ONE OEM COREA NINE GPE AD GQ DUBUR ERED OF BE WOR a BR ed SOE GEARS Lee ete re tie 
Ss * 28 ..-“S = ie a . . » é or t e@edt Be verte ote¥ ze wheat ae Bw eke PE 8 Ah 8 Te OEE SP Oma oR BO Oe IS BO EE ORS EO et B08 Fhe a Oe ee peel ce Pg ey 
~— —— => . man OA SE Oy pe A mA Z 5 ‘ 2 : ¢ ft.e 0 are ie o: Oe ee OOS gee ee LEER 2 OO M8 OV COCLT TO SS PID AAR, TLIO LG Sesh 2° NS (yet OD FC ay pal get pn hg 
——————— ans Met PONS win ws as a a - - . nap ils . ve al ai . a - ohh ot OF 0" 080 F ¢ 8S EO Ee Ce EE EET OC GY FF RON TIS Ferze-s%, oP OF ae BIE TIEPS LAV SONS 8 ONE TEE ees OF 1 OE et ah Oe ake ob wat, 
a Q 4 ™ 1 i actA = ot td ~e@< os ’ ° 7 ® 5 a al wot D Pee Te Hay eh oy te ee a eee ee ee ee ee ee 
oe ama ™~ pte a pete ‘- ut » E . be . - M n e see (ewan - cd Soe ae - Pee ye Oe 2 oe PEM PO Fe oh OO Ge RI Ce Ly deters OPE POE Fyre Ofek ee ST AS PUERTO ete SE nt ESO Be et eae 
— = es a neal Seine i a , a _ é 4 . ob > 2 alls ve 5 ov ot MOB rene reer of ety oF pele REIL ORME DE gf URE A PBT TG at 8 CMPD BNO EE Ee Cee ome Bw tm Oee> mat ere £2 as 
——eeee toy pete yao, Me ~ apna: “~ 7% -— ‘ a "y . a . as ' . a e . batted ‘ sCchapae aM Gintig® 9 OFAE! sama ee? se A tee see iS x Te ee Le ee ee 0 ens ene et aee® ar 
|—— CSAC eee én . bs ; 3 - owe * weer of ate cpssheliiad ts co 2 atten e? GF ate om 7 ot ptt ning OR oS AOR ENS 06 rede ORs PENIS! BAER 8 OP 0G lt IO FE DD I LF AS oO A gat 
_—_——___ spay OUP TOeT. VEER Ov pelt. as vf 5 twee? . ~ ° 4 - is 2 ‘ yao z ep . cas ; were ru Feeety or eee ge Oe Crean 9 HOPG Oe ded ee ed ee a a ee et eet PP 
——— pre TWIN Se Sec ading | SaLsk rare COree " “i = : = a ah ial rs fee eure ree 3he LOE Oe gh he LFS KL REELONGE TENT a8 GU Pe OLIVA EOC pH PINS we BV abo Sere? LO} AO CA Hl STEEL APD OD HEN 
- S| a -- « v aah ey eer aL ald 4 « . = 1 me e . ws td were # ae eles SF Hide ene Mees eA sey coum Pugs eo ays we te PO grant oe at Ge eee ek Late SU" pe tg rel gl ge tors eae Pa Sas Ong tet Ae FE Re, my es 
ot Sane te eal wn? & a© Lae Panty. dhe te SS “a ty * a A Prats F one = oa Oe pr Pee gt A AET PE? OF og * OH se UE Fm Ot, oe RET OTe BNE OE KB OEE BA 50 6 OG EV8 FAO RON BOM gt ONO RO EE, CPD gh Set PtP ag aes 
em BEM A Rmabee seh pW 40€ cams J — "i Ton ia oe R nue rit 4 ofa “ oe oe ae ae ewer owe wee Pd ee = pa OOO BGP R42 VAN PTE! EEN D0 OLY OEE CTRL AREA NOES ee ET OE Oe Ae EEN gfe pe 
owt a ~~?" wow ee Oo bdetre ee < : ¥“ ot 5 he - a . owe 4 A - 2 rr ot re pease av Yaew 6} OW GCC Toppers & sree PALES ATO FO WBE FT dare sget eee ge 9 are oy EE Oe gen Glin By ee Peay 
: WE Pu C0 FEF ty Se wuss Fe & pt ee et TA ae ™ > . . —— - ? a's ete , FSH ges wet eeae oo tarak of tee ry SF NaHS OP Ele s gree a sera ese sr et seers EF pt OP -8e PF 8 oe FTE ay ot Oe gy ee? tan Es gs em 
poe ~ te SOS - Ch OAs BOER GTI RT Seer Ors may ake & ay " a x + ~ . af ae: * t jee . 5as8 shy tee peewee let GENE” 6. Sn reenter t atat = ang rere Oro men YS Ee PER ARO BIG hohe Pathe? 0 eg (ee COLL cE ered 
argeereyehs Sete SP ME EN SO Ee en web po vie, Chile TO ean cea RTO . ae Sas . : ‘ _ _ he es ¥ eo oe wid 4 gee ae ee ee een een ee en Ne a pbbehinetiintnMbteied kbs al ad on ot ak mmol Poke dnd od tes denies banana ote 
eae WE NTE IST ssahttond oth Osa # CT Lavchindsah tibet Anh aei ee et =e ' pe « mip | “ 0 aay ‘ . ‘ ‘4 lO ey | We vere tay ye prow POM a Che Te RE TEIN T OOS 10 Se FE GRO ETS MINN ON Ot fe HOt TEBE SEMEN 8 ar I ER OL gh ete GEIS HOO IA Oe Ohare HOS 
Cae Re cares ye EEL ET Eth OMAN Sa PS a Sen NID ILM, OE ON peek CA FANp HVE U Since ar — < . : 5 =e < x i 2 OB EM Fre Pe FPN EMD ITO, Higa ATH 5 PERU WO OURS Wie? hee Me TI IE SCS 8° aL eeere oom April Sh tinciea 5 2 tah lets fe pees ee ae 
5 a ee a SES OS EN NT saith wey taerry OATES te “ ein 6 ce Ot —? “qf v ing , * * S y a a - an ; 9° ge paris Og gts ge tole Cee ates 2 A pert eeh 2 <i gyaifialgtee "ut swrbas ee wery a? a? gt bipedal dal iaelinel ela hdhtedsiat maleininheneaterend 
sy nag A He HS Fa Fe plecicpert 2 Gee TRON le ee ‘r batgtn AS s _ a “ = < S = a, 2 é = LePyn @ HO OV ON FO CF = 1rd 9 keF NE ror ate Cee ew eNeNE = § F. YO SiMe Nomar? poke ae ae FEES Oe 1g eo Ope, 8 es Olle FOr ae al yee ee 
ge one SS EE re on eee “w. < on “ween ae Se Oe, OY wetet ow «= Maks ben ar ‘ > 7 e . -, 5 a 6 TFA ESE” o> Fat hae a 9 7 owe LOE GP COVA 0 ERE LTE AE FE ROED RP ADT FO YE OED 2h 0 OP STE pak gg) OEE E? OF. ge ree, 
meats Me AS te Se wk = ee ap rere oxwt Dy oe O70 Fe Ve ee ; .. “ =f er "] rer _ “ . . ‘ Le ‘ e is ‘ila Ld ag? g Os Weer Ye Ee? wwe o® oP Gh at ow Se eer eed Ea ere rO ees e 2d 8, Be nw gt 8 p= ie ume POP PO 1 et AP Leet mien ane 
rey QE LA ay ONES pao apetraeaiy! Se arte One ht B Fu Won Bee we EN nen y te eXesee* 4 = ing » - a rw F r Sete. ween’ page ge 4e TESS eS YT OOP PLEA E L0 BIF O ETUE 0t BE O G AOR Tt OE EY EO PEt NTL AM F abiuatsa ar paive, 
ogee Sg? Tt eee, WOVE SEE NNT OS roa tg ERT ee EFI OFA Se TOY ETI E NES TO bara trina te er | . . ae ¢ i 5 r f ° patie ° SO BTe EPO aE RE ENN Eg OP AE rk A NCO" OF SGU RD ELEM: 0 OBESE pe MEET 9 (OL PT SI COTES AUN U Beatonwie 
ote On ate CaM PET etErE Wee re TS sadepmtSoa ch re ery NOTE EES SN SS rae ies eee wie ~ “ d ¥ Peeeres oS ’ fe FOG OVD OEE FIM CT IOCH ET OE SUN wee TW oR AE opal D ONIO= 10 a FM BME TR ew Id og Ol Ge Tol FOIE STII U LOT PAE Os 0 mde 
eee 0 0, See THEE BETS SE EO ER™ Soames atu -2 PL RID BE Agee tatese rd : aes a? 4 ~ 5, we hy = ' ~ = reg . eld hete 4th wrwaer $F Pate Pat pe At Oe ore ey pid ot er ee Ss 9 CORY Ei OS Roe ign gee IY a0 ere al coc hehehe cull atattesltineatt SG Ulget chad arm betaentnie 
epee Os RT Ree HH YS Lert n cage WIG Eee oie, me ove, | ar weve bd z ‘ me Cow - ae ge mne ase fs ep Agha ere re wate eR ER LO Fe PERI Gg EN-DE FO MTL Oe EEE RANG As DE yh fre OE FOREN ee. pers wry 
Se oenae Cad aEee oe wre F prc neers Fa EO BHT NS Os cited, Bw : OM Saw ee r = enig= p= evs ers ° * = Poh aL OL LE POL ae AS OE eg OK aE OE OS AA he PRA a Kes 1 f8 FANT OT FEATS TOE Des OS Rae RN rene Aine FA ab © 
ce $= Ren oe Herel, tS atin)" Taats Raph tO ng yay 5 Wer sere eek EE os in be Pesereryse "Ors is 1 omy tS 2 - me im kevese OMe 8 ga 1 TE RENO RLTT Gf? OF OF GE pel a Tope firret uh «5 ones Be F BLE ABET TIGR OEES 8 TIT OG RL ge fs TERS OS eS A, 
= oa rose i margete tes ceet? readin! gps tote cy Pea Fetes Ow en su ee tat “tat eve ere aH i ‘ ww tf me P i ye : a one ryt a tr ot é a a> wherein SW) 5 gi, eae fa0 e Ay BOLE ATES 0h ST. OI TES MEN ELE 9 Eig O19 Le OT PLE Apr 
pees ne OTH am bea eS poeta te Ow ne Oy Ree CEE NS agirecwryrcat, ot phn . ve , . 1 . . - ‘ Pot Hu v0 id J : : ae P oO Oe We eee MACE EC MIT FEO AGM a BO TPES PLE CEOS FOS GO SOES oF BE ENS Fgh EM Ny anger glee te bE ER STI ITO TET W TE © pe wig: 
esses Go ES ery “tre eng et oe TOME ASy Eee La ea 8 Sg a Pa TYPE FE MOMS fe ASS pth + K2 % wees Mh Oa Tet rem we . oe er one ae ore Fret rage & PaO: FONE tO 18 be FOE Sp BE OEE OS EE EE Ew 0 rtp eds EET rete 
UC peeo tee See 6 BQ eere ature t Om coke ae ms Rt ayeut 8 Ne hk ey wee nae Sq eceerT et Me FPF al zi ; pe Ne ome 7 “ 0° Page Wiss of a?’ r'e Faby gotta 009? Ew ate See ae eee eee en Sa Pr Wary eee ae ee era nga ay 
Lege eer sy STOEEY a er a ne Par rae em ag Owr¥ palit te aaa b : ere ene one Me ag pe : — yh bn m -! eA ‘ ’ y¢ = 4 *y Poaeew? oe PE Yeo, HOPS MBO FE" HIE G wt PP ae ae? 0 tO wereteteateeer Fi Ube ass satel int ta appnteher tl Cog atthe ah 
Tee PETE ER ee SORES © BF EE OS wep PTO: Ae iy ge ret Ye rere pan en BAT rove ¢ a ‘ - . FCP IRE FP I Ct Te ay eT 0 OE YP EP oe BO Ul EA Brey EP PATE OO Ta REE FP ETUTE BCP HEED FEM OST OE ROT we pipe 
“% wn Gres -da Went eyes Cx Se= we Sarg VERE 2E in BEd Ee VRS nen Wort eA CTE as : to . eo Pernnse £6 n Ph O08 LE AC LY te COV AER AOE BOS Le ROR ES Wt Det ot CTT UE OER OO f ey ain epee ba oE SN OTE aT OTRO T He oe ere 
cope tae Sree Soin, der FET ETOP Oh GCE ONT os Je ee 7 eH. MQM => Pe 8 “ye . . r pot) 7 ¥ ee lt ee ale ahd ‘ ¥ ° F Wy Pore Sse PEI Be CE BOT OO PON ENP ITE EBT aT gh Bat pO DAO alin BID wat gi wrapping? 655 EUs ren 
~ ewe WrErede SESOa Tee OTs “OW Se eS ~ ‘ Be we kt « 2 ie - a ah ~ Y y me « . ; f n! 6 POA EE BEB Oe! OTE ISO PES is 5 x ad ae 3 = a swt 
Gea PEAR Hy Sey hE BIS pee To ba tn be dt ete! i AP ere & EEK Mt + is ue ~ we U Ss ery (SIO? ¥ * > ot PPh enw Tet _ OPEN IP OE DEL) OFS? FEF? F FOLLOW Pipl Av Geen s bees or Eo at eG Og @, OIG Scag TG oT PIE OS a pare 
wave -Rer Sree Hee ean ote FRE ie SL a NETS HORNE ROE oe eee rpg ht. MSN EFTNN VY - .—* ote ee F ” ibd : . - died. "Bede t oo Regt @40 F6Fee eH TE NS ory, nb 2 at ra Shae tage Se Ce NERO, 8 ey ie TOC ESe O! © i Me Ras? PG FI io ES ON, caayly 
ma rosa ea borane TOTTI a eee FSET phat penn et ted ew MS ates MAA er = ail i o,° oe . We wed f . * nt, aa ney 4 we iw fer Loe ol UT Maree “ aot mo para? awn Woes e808 a oNUeioare VOW 8s be WEN WUY aia tet ina enE SEs tees 
eK Fee eaten exces eee OS oe el bee ae YT boi, cL eaeetelite rf “ ePIC “e Si ath oaks , > a ee tn * mete ‘ . Fi Ml . - « ality: by er tabesd prey eI ee ei ee a ie ee he ek Pe el Calle hp Sapte hla Coepat © te Bs han me wy gio» Lema 
atp erat) Pate tperee ca re WEEN SS ae erecta ns FOR POPS, ter ER IY Bae PITY p= Estee oe ae ernee wt wow : re ‘ : re ’ m 08 EMCO ares ppt ARO Sm atty Cv Ct 8 ROE pea, ew cine a Clee x Os F O89 PCG AF ign 6 aLIP OF 9a e & OIF OS HN oe Pa B06 OLE We WT kD Re oe ah re a AT naa peg > 
. eee Fre O- ay wae eS a oe Se ORO TKETE BEF Se Oe eer trae | — . vey i a 5 ne P oF AE OST ms? . ales er a Td coulda bl oll ain dal ahnalien iat a1 al lah oath ced thie aaah eed oie 
2 teed tC oe ee Oy MSDE % Ase Gey Fs WE Ope Oh: Bue fe OH Ha OE tel dm, ld ee eperewrn el QA ¥ pagal SY 5 % . aA © ¥ - a ‘we eee = gt gee ’ lag se Cel SFO Eee gt 8 bie & Wile ofit Bt ed Mier geet O08 m0 ard Tee oS PEE ES Fup Ot FFF WTI at Oe pe eT AE EP? 4 sat IP a Jef 
Fe Oe Sena Aten a CORIO odie atrcea- vey 0 eet We Pag PNeEEE Ver eaTt © Se 1 Pe oe Sut ¥ " = ; Lng \d .. "1 , ‘ Lacs debit ag ay yeep tie EE EGO EO GREEN BO GRE OA TILE IONE OTE green OR PETE RE ye ge A Ta OT eee 1 ie PEO err ge 
cee weer ame tS Pr ELE TY vase Soe S™ cw see a 6 Se Ae Fete WES UCeal ye were arte * aH rr ee ‘Sm "a . . = r ¥ i Cappel ota pel ae ee ot er ¢ Sule EE a ET OTE EES eh PLTUTTE 69 96a Gh £1 O89L SOF PTE FTAA ETE ONG. 20° FERS OTE ONE OE WEEE F aS PER EI AAI 
oe Venere KS PNW Dore on UTS e = tap ated gro USS Urey aL Oe ) r A retain ae’ 7 em oe yemres = : ‘ od - e , F ow Sap a8 + Ll ia ares PONE Age GENE HE OT WOE GTB ofe ep ah ONT CUT OF A Bee Op! BLOF [RBI T? WA OO Ek OR RCI T AIR Bo Lo we Tyee 
Cee et new ta ealvtateee Se-te Meese ban RLS: Se Pee ln ha vo SOE IOS ' e 2 we cer) <i i a ’ "ae alin fee dapat Ola a 4 CID Fe gPn yh AA ROW, og ge 8 te HEE oS carga aE Ae Fe UIE A ANAT IES Hy OREM POPE EN oF gH ENe Oar CHR OL SDs BATEET GE UE! AU ow ohn pw 
ated ‘ eye er eee? CUD MeFewe Webs My Noe + ha rene Me eet e wed tare i . P ‘ thee dike Site , a ° eae» Come r 
ioe OU eye are ‘ ee oy of U2 Me OY WEY a, “ih iat he the ft = , ve ope rn ? eres PICEA I WEN HOLS BVA Oe 6 ORTON GS” HI INE AWS Oat et AD FEFTETIT EY 6 Come S Os FETE ~ FONG OE Rane, 
wb ie eh eee Gy a, ove Serene “ ooh Fuh ews bee at tee) r cr2erwt es ‘ vu pe weed ’ aver =F tye eae wedowee. é 
parce que ¢ Weare = EMe sy ET ER W/E ewe Pete 76 PLR Core ob AY «mre 9 & trer ote be + vv . . . ' a ; Felt hal or ae we ~~ Bie PVE et OE EEE 0 emda C1. pag Rat” 98 Of or ERIS a oF LL al tel atelier cnt aol Soialelattl pA eal al aaron! 
ate: CUO Oc Magy O70 PEER SOR Nees ebeds 16 .G EWR OTN 8M PR YE SL tee ee vn F “7 vag - ¢ - . ¥ Pls x owt gta et operon Le 68 A NEN ar RN OF BN? ES EET. He, wt CLOT AIT BOER od FUSES PF hae O WES TNs RerteteD 
% eqeraateettade se ue At fH ETE » ay Miley, Fate Wit HG URES PPD ey ote Se ae " é v . ae cz " ‘ ee Cert tttanl ada fled dog a eh 90d e matt eh POH ae HOOP EUL 00 Hage ge 6 Ped 9h gt OFF EU CO ett gt E ERAN ws 9 FAR FOE ge HOV BE AE ae pene MAE wes oe 
star apa Sy Syte BSNS TE ee caren WEG OF ROE STP R SOE OS OS Sew “ es , : f °° a a * rw wer fT digest « ates Jour pan emake CE a TOL Me GPT” CIPS OR a eT AOTC ae TRIE T SD 08 NBO Prick a PE FNIII Th eD ned ohare BoM RUE R RU REY aed 
NE payee NTOMOTY may iene ep ert ra bog anh ry Sh 8 Fe (ee rts ETAT” BDO le S Prepay T ieee 4 i <p i ye F c ats ccd ae were babies Fe DR PE OS ACID OLE WT ee VEE ee Fr wUP ARAL AT ATL SCAT Oe Perrine NEUTER Es ab AE et are PoE e He doe 
> ae Nast SFE Rh eae RUT ON TE ETE SN ©: hate Me YDVir0 WH: YOON Fo-UM MATES » Suvi et er plrhits oe BEF See, oy 4 Ce oe nd steaatagpion SL lint? —_ dreds Pe ge eg Me ge a ly CaCO CRE VF WO Ie PE OE BRIE 20 5g BOE REE COT AE F FUE A PO 1 8-o HNO Ie gb Rataneerreie 
Se au nerrath £0 seek Sra ny vere: te panded vg “paver. “Oren wsa.vett Wow” hg. - mataets Brebw “ oO wer. <a me . e sd F ez. ie oo Aas =f su oie a Pw i ee Fe SUTTONS OUT TR. M RE oh aH OAs B80 A COMA OF he Ie TAF BF SETI EY Ue OCC iNs eae eS aoe Hs Faery 
fede mrad ely hPa we wie pt Sa ely Pe Ey ETH HY OR CET Sy ba Eee yen’ & ‘ ‘ : a , arms “SC ‘ Seeeste se _ 4 ver yes FE FORE IM TRL TE OR POF al = 90h“ O Oe je decried ee ee Cerny Le ee omnermenes 
ona thy Gri Ter tap Awe we ~~ erteth Fyveey. “BCerer se yee Q ad aeyrt . 12 ‘ whe 2 x ~ ‘“ Pim « me 6 PGW ES ARN! OO. (Ore UNE Rg Se WP ee oF Fee or, oe 9 GH Wd Aloe Pe DOO pl FE ine ‘ OOO. We rs yet ee wtp igs 
= J ayvew rat a ee a Cot “on de le Seofid . 2 . - 5 = é i : 4 Ny at? Wage Pir F 9 ® oe a le Re 08 0S ate (rea pre So OP WRN FeV ey a DE gr PETER OW en aren renter pt 
oe ep hye DR OES SSO a ee, os Sg edhe . « bat Sethe ‘ ‘ : aryna® ’ « 2 ee oe ee ee be! ; : ‘ 
at a Sere ae yoo ~'* « Ane | vel stn thd ° it r . ba a ie ‘ . Lae ee - " 019g” Ue eA oe a Sa Eee 5 OP peewee hy, 5 6 at ORES UT fT hE ira at sheer pibm lana kIT Gey aieet Pee epee ote oy 
pect we me Pk Sh ces Gy te < ew erev ig ee oF cartes Ener a9 be ‘ y ‘ , Lee vere ; ele ther q : : ‘ 
J a an Medis ome me OCA? FAROE A ORY? 2 HT OF: 2 ae =) ay ot —_ ¢ . wer DLE LOLOL PE IG a Ge IIE IIE pee amabe HIF ITE ATE EE hE EP BENS Oe pa OF OO EO © oe PORN Had Bren ame 
cm eae Eien: Face Peo Sa HS FOE N NS easel ae re ara OO VOW C NT SE ee eT 3 3 * “re eres 6 re ee ee ee aR SOA PRVIWES AP Mya eV SW A jewel. Pwr ve BST Iak Ooh 4% TLS Hira MWe pret YAY SON SP wheres am SEpe tN” merges Gybey 
oo ex yes ya tak MTOR PRESTON EIU OE OS Og Rekioeds “UEe et a i “ — PE gy, ve bee ew ye Zea Ge Ae ne ead 6On pe COly yer a iar ine OATH Ta? CWUIPS Gat gr TUTE a ve BIT org TE Kise yop res wena re erie 
_ Les orere een Fe eV IG OS ~— hla aa Aree te Ser ss * aly . v M a) a] 4 _ Pa ee Tee i ie eae aed tal oh a a th a DRAGS he A LATTE OR PUTO TI BEd ot wlao ms 18 gare omy 
reper errant Seg) my Ewese FO TET HSL ET BGR TENET eae Pale hi VI PET) OVE Oss EE PX hel ee ¢ OM s . PS * w ‘ ai pA PEP ACT la Atle i Ce PR0cn V4 gh indy despre Bie yWuelr hese eee ore tial de adele bl hiamned a 
ae ee ee ove ve whet ey ere le WEL ne ving mg yh ME OTOT ES OF Sy US ace at Che > . ¥= : tt Fl , a < f rerak (heplss 167 0 PAH Mii & COG ube ERE Eaten Gon tg eer’ 2 BAe eid Sgrbs by het el pe WA She wi acer vesarertetune, 
Fe oa cen en Cu runn ce ray EN Te hey el PO SEB ied talc Pi OO RIE Tt a date Ps 8 § Tees? ‘ 1 ’ ve i vF pe : i my ce pewtns eS a FR A NE Ce GNU Ce” bd ALG WDE THE LON UE I SREY Ty 188-0 HemHt~ GU NCV YS st er ete SB EYEE OR NOI ip: 
yeas ho wen mrepsem “92 8 PWoe "Ss Sov Pe eres Pichia he pret iwi 7") Aap eae a L ati , ¥ we Pm Babee p erie ehtnure F-HUNT wet: Anise eVi¥s Heb 0 eater wee ca Daa e Att ember obits TAM ale tetlealil te ada 
PPE He WUT OS ESE OTN eT eg ge IS TNTTE UY tk i eth) ies > a, ‘ i.e ° . : : FETT EP EE Bed Rea STE eT a TN we pple at Deel La pha th ed é Lid FOS GEC CVE LOUD PS OR 
Ts tn Shed wen jp). ey a tke wen TT apes yor eet Aree bs ‘i , : 7 ‘ —— epee Tot er AG BOWS Me Bx Aves Ata Clad: or vere OF Be ae uae “toh PER ES Ps Fas rr it ere ee 
WIV awn en Sa APE R THe epee ae CNee. we Re AE DOE SS OS de "a ef & : : ¥ 68 OR TD POON ae FTE R ARE I CAE WY Hi PRE EOD 6 SON GLAL OA Pe G08 WENT CIR SU eC ATEN gtr A a pts weg LS tase 
aera en ecenhe areas s Pureh FUE eT Ue ee ene re PVPeTyI OM APEETN PL arexr ate ens vs oye %. s* Pie. * yMre ABE AAA ERLE I I RF NEE REO 6 Ne Te OP 20 t STi has WME Ih Oy Oreeinee4 mi hese ergs inden 
Sain cep ow es mmeutne ety £7 28 TOF OO I on ail ome TET lan eS og re 98 UOTE b tpt, ai : ’ ‘ “e mich 4 ; : : Se ela a a OM TE OM a EO OOF Tay NT DE Tipe 0 TTT 8 OOD Fa eb We OP CELT TUT Ue Bi eT H FRC ered ae 
or dachiplabon pata PF eee TS BT hla dedi te aS net See Ti i ed A, Se er ak A dak SP See wert: ’ - ' J a z - : Seah ee De aN UE ot ENE ne DISTRO OD Uriterrcwe ne FMLt ew ee ee TE UNOS Tw BOVEY IFUL CATED 9-7 NE Oe aT Bat 
pe rd pe ee hae pbs vaete ey ee Ahr atone thy bh “Oe ’ ; oe ah . - ar “ Oy et ts od Dee ee te ten oat ee Be Se a a AEA Oe COTE! TENCE PO ok a PPO 
he Web re Weshtnt aad ee es ate mtn oe een wteyes et & - od te'ttrs BECP NT Cae ps . ag . ow is > ana ntae nit dhtekedhaakansso ndrnsiiliete «oath G0 on satan deena, 0 ont Grit aes A eee Gen Ge Bantam a tots dante sid ee _ ge 





